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FOREWORD 

& 

fhis  final  technical  report  present*  the  results  of  the  Distributed  Ptocessor/Memory 
Architectures  4 DP- Ml  design  program.  Tile  report  addressee  specific  task*  performed  to  meet  the 
requirements  of  Air  Force  Contract  h**.  F336I  .v'4-C-IOIK  for  the  Atr  Force  Avionics  Laboratory. 
The  report  was  written  and  research  performed  under  the  direction  of  Mr,  M.  Moore.  AFAL/AAM. 

This  report,  and  the  engineering  data  submitted  with  it.  contains  the  results  of  the  DP'M 
design  program  conducted  H>  Te&as  Instruments  Incorporated. 

Principal  contributes  to  this  report  are  Mr.  G.  C onsoher.  Mr.  I).  Ackley.  Mr  M.  Ilickard. 
Mr.  R.  McAfee.  Mr  T.  Shipchandler.  and  Ik.  V.  Gylyv 
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SECTION  I 

INTRODUCTION  AND  SUMMARY 


I lk*  purpose  ot  the  Distributed  Processor  Memory  Architectures  < DP'M  i program  was 
" . . to  extend  the  DP  M \y stein  concept  work  to  a detailed  system  software  and  hardware 
design.  I lie  emphasis  of  the  program  is  to  develop  and  use  a functional  simulator  that  will  aid 
and  advance  the  design  effort ...”  This  report  contains  the  results  of  this  functional  design 
effort  and  a description  of  the  simulation  and  analysis  tools  that  were  developed.  Pertinent 
design  tradeoffs  and  the  functional  operation  of  the  DP  M hardware  and  software  components 
are  presented. 

A.  DP/M  SYSTEM  CONCEPT  AND  OVERVIEW 

The  DP  M system  concept  is  essential!)  the  use  of  a varying  number  of  simple  homogeneous 
processor  memory  elements  <PI  si  applicable  to  a wide  range  ot  avionic  system  processing 
problems.  Architecturally . these  Pi  s can  be  used  as  standalone  uniprocessors  or  they  can  be 
configured  in  a distributed  network  as  shown  in  Figua*  1.  Serial  time-di vision-multiplex  (TDM; 
buses  interconnect  the  network.  Two  levels  of  busing  are  provided*  a Global  bus  can  inter- 
connect each  PI:  in  a system  network  and  a Local  bus  can  interconnect  multiple  PEs  clustered 
together  to  perform  a given  function.  This  cluster  of  PEs  is  referred  to  as  an  Affinity  Group 
i AG).  Input  output  if  O)  for  a given  PI*  to  an  extemJ  device  is  via  its  local  i O interface  unit. 

Four  functional  modules  make  up  the  DP  M PE  as  shown  in  Figure  I.  The  Bus  Interface 
l nit  (BIL’t  is  the  hasic  TDM  data  transfer  interface  to  the  processor  and  memory.  The  BIU 
translates  bit  serial  data  into  parallel  data  words  and  transfers  data  and  status  information  to  the 
PE  processor  and  memory.  The  processor  module  is  the  instruction-sequencing  and  data- 
processing  portion  ot  the  PE.  Its  computational  capabilities  are  equivalent  to  present  commercial 
and  militarized  minicomputers.  The  memory  module  provides  necessary  program  instruction  and 
data  storage,  and  can  be  accessed  by  the  other  PE  modules:  the  Blli.  the  processor,  and  the 
input  output  interface.  Memory  access  is  local  to  a PE.  i.e..  access  by  another  PE  or  shared 
memory  is  not  pari  of  the  I)PM  concept.  The  Input  Output  Interface  Unit  < IOlU>  of  the  PE 
permits  d<g:t:*l  lata,  command,  and  status  information  transfeis  between  the  PE  and  the  external 
dev  ices  in  the  av  ionics  sy  stem. 

The  DP  M concept  is  based  upon  the  projected  availability  of  low-cost,  medium- 
performance  PEs  which  can  be  used  with  TDM  communication  methods  to  provide  a means  of 
cost  effective  incremental  system  processing  growth.  This  potential  is  enhanced  by  the  use  of 
common  modules  to  achieve  increased  capability.  The  distribution  ol  small,  identical  computing 
resources  also  promotes  reliability  by  lessening  system  dependency  on  the  correct  operation  of 
any  single  element.  11ns  natural  distribution  of  processing  tasks  along  avionic-function  or 
sensor-pjrtitiomng  ’«nes  allows  a manageable  system  computational  load  and  growth.  The 
advantage  of  DP  M in  avionic  system  design  is  possible  with  the  continued  evolution  of 
improvements  offered  by  semiconductor  technology.  With  the  requirement  for  reduced  si/e. 
weight,  and  power  for  airborne  equipment.  DP  M offers  a potential  solution  to  these*  primary 
goals  with  its  flexible  building-block  approach  to  avionic  processing. 
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Figure  I.  DP/M  System  Architecture 


Specific  tasks  addressed  in  this  program  were: 

The  functional  design  of  the  DP/M  hardware  and  the  development  of  a set  of 
simulation  and  analysis  tools 

The  function  design  of  the  DP/M  executi . e software 

The  study  of  process  construction  methods  for  DP/M  system  software  and  hardware 
designs 

The  examination  of  the  role  of  and  methods  that  could  be  used  with  DP/M  to 
promote  avionic  system  fault  tolerance. 


14 


B.  SUMMARY  OF  DESIGN  RESULTS 


This  subsection  summarises  the  following  DP  M design  activities  and  results: 

DP  M system  network  design 

DP'M  functional  simulation  system 

PF  processor,  memory,  and  internal  bus  structure 

PF  Local  and  Global  Bus  interface  Units 

PF  I O Interface  Unit 

PF  technology  and  cost  projection 

Fxecutive  software 

Process-construction  study 

Fault-tolerance  analyses. 

1.  DP  M System  Network  Design 

The  inherent  design  flexibility  of  using  small  Pts  to  build  different  processing  networks  is  a 
key  feature  of  the  DP  M concept.  One  result  of  the  system  design  effort  was  the  realization  that, 
while  the  coucept  is  basically  open-ended,  the  functional  design  of  hardware  and  simulation 
programs  had  to  initially  assume  a well-defined  nature,  it  was  not  the  intent  that  the  small  fixed 
functional  resources  of  DP  M solve  every  avionic  processing  problem.  The  homogeneous  nature 
of  DP  M also  stressed  the  careful  review  of  all  system  design  features,  since  all  PEs  were  identical 
in  capability.  The  aim  of  the  system  design  was  to  allow  as  many  options  as  to  the  use  and 
application  of  the  DP  M as  appeared  feasible  within  the  limits  of  future  technology. 

The  baseline  DP  M design  has  the  following  features: 

A dual  redundant  Global  bus  system  for  inter-PF  communication 
A single  Local  bus  per  Affinity  Group  of  PFs 

Functionally  federated  PFs  or  groups  or  PEs  devoted  to  the  processing  of  a given 
avionic  function. 

Both  the  Local  and  Global  bus  used  a distributed  round-robin  bus  control  scheme  where  each  PE 
interconnected  to  a bus  has  a predefined  allocation  of  bus  usage.  This  allocation  mechanism  is 
programmable  and.  as  such,  super  commutation  of  bus  messages  can  be  implemented.  A logical 
bus  message  identification  header  is  provided  in  which  a message  can  be  broadcast  to  multiple 
recipients.  These  bus  protocol  features  are  provided  for  both  the  Global  and  Local  buses. 

The  Local  bus  facility  is  primarily  meant  to  allow  the  creation  of  AGs  from  Pi  s.  Because  of 
the  likely  closeness  of  PEs  within  an  AG.  a single  Local  bus  interface  per  PE  is  provided.  The 
Global  bus  interface  provides  for  a dual  redundant  TDM  communication  line  for  each  PE.  Every 
PE  on  the  Global  bus  can  participate  in  primary  bus  transfers  and  simultaneously  listen  on  the 
secondary  bus  for  a “switch  to  back-up  bus"  command. 

2.  DP/M  Functional  Simulation  System 

The  development  and  delivery  of  a set  of  simulation  computer  programs  that  model  both  a 
distributed  network  of  PFs  and  the  key  design  and  performance  features  of  the  DP  M PE  was  a 


15 


*ey  result  of  the  design  effort.  Both  simulators  are  capable  of  modeling  discrete  events  using 
time-order  lists.  The  System  Network  Simulator  (SNS)  synthetically  models  the  asynchronous 
operation  of  multiple  PKs  that  are  executing  programs  and  a distributed  round-robin  bus  control 
on  the  Local  and  Global  PI:  bus  interfaces.  Hardware  models  allow  simulation  of  the  program- 
mable bus  control  over  a user-specified  number  of  interconnected  PEs.  Models  of  executive 
software  routines  have  been  included  to  permit  the  scheduling  of  programs  defined  as  directed 
graphs  composed  of  processing  tasks.  An  extensive  set  of  reports  was  defined  to  analyze  the 
results  of  network  simulation  runs.  These  reports  provide  bus  loading  per  user-defined  time 
interval  and  individual  PF  processor  execution-time  loading  and  memory  usage.  Similar  resource 
usage  reports  are  available  for  different  bus.  PF.,  and  avionic  software  activities.  The  capabilities 
of  the  SNS  are  also  a vital  part  of  the  process-construction  methodoiogy  for  developing  real-time 
software  for  DP  M. 

In  contrast  to  the  high-level  traffic  simulation  available  with  the  SNS.  the  PE  simulator 
allows  for  detailed  emulation  of  the  four  DP'M  PF  sub-elements.  The  processor  simulation  model 
executes  each  PF  instruction  and  alters  ail  programmer-visible  registers.  The  BIU  hardware  model 
allows  for  simulation  at  the  register  transfer  level,  and  the  IOIU  model  provides  for  a high-level 
functional  simulation  of  data-channel  transfers,  interval  timers,  and  the  interrupt  structure. 
Facilities  are  also  provided  to  define  and  generate  interrupt  stimuli  to  the  PE,  and  multiple 
requests  for  access  to  PE  memory  are  accurately  simulated  by  priority-resolving  logic  and 
memorv-cycle  stealing.  Debug  features  are  included  to  permit  detailed  tracing  of  instruction  and 
BIU  operations.  Memory'  line  printer  dumps,  execution  flow  path  counters,  and  static  and 
dynamic  histograms  are  available  for  post-simulation  analysis  of  PE  operations.  Interfaces  are  also 
defined  to  permit  definition  of  Local  and  Global  bus  message  data  transfer  sequences  and  error 
condition?,,  as  well  as  the  use  of  detailed  simulation  models  of  external  inrut/output  devices. 

3.  PE  Processor,  Memory,  and  Internal  Bus  Structure 

The  PF.  processor  design  specified  a 16-bit.  8-register  file  microprocessor  with  microprogram 
control.  C areful  determination  of  required  data/control  signals  indicated  that  the  processor  can 
be  implemented  in  cither  one  or  perhaps  two  48-pin  LSI  (large  scale  integration!  packages  (a 
data  processor  chip  and  a control  chip!.  Other  features  of  the  processor  indudt  a uniform  set  cf 
instruction  fields  that  simplify  instruction  decoding  and  reduce  device  complexity.  Functionally, 
program  memory  is  addressable  to  65K  words:  however,  most  applications  are  expected  to 
require  4 to  8K  words  of  program/data  storage.  A set  of  forty  16-  and  32-bit  instructions  have 
been  specified,  and  primary  emphasis  has  been  placed  on  maximizing  the  efficiency  of  those 
high-frequency  operations  typically  found  in  avionic  software.  An  extensive  yt  of  16-bit 
instructions  is  provided  to  conserve  memory,  an  important  factor,  since  memory'  will  eventually 
dominate  the  cost  of  the  PF..  A standardized  set  of  80  internal  PE  bus  (I-BUS)  signals  (including 
20  for  power  and  ground)  was  defined  that  facilitate  intra-PE  data  transfer  and  control 
operations.  An  added  benefit  of  the  l-BUS  is  the  ability  to  combine  and/or  intermix  PE  modules 
implemented  in  different  technologies.  The  proposed  DP/M  design  is  easily  implemented  with 
current  semiconductor  devices  and.  as  future  LSI  devices  become  available,  the  PE  can  use  such 
devices  so  long  as  the  standard  f-BUS  signals  and  interface  conventions  are  observed.  A simplified 
programmer  maintenance  panel  interface  is  provided  via  the  l-BUS.  and  the  i-BUS  also  offers  a 
method  of  providing  system  fault  isolation  and  built-in  test  (BIT!  for  the  PE. 
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4.  Pt  Local  ami  (ilobal  Bus  Interlace  l int 


An  approach  that  emphasized  Imictioiial  ii u k] ii lai it > ».i'  used  id  the  design  specification  of 
the  Pi-  Bit  hardware,  fins  was  particular!)  important  since  t-.tcli  PI  in  a III*  M network  is 

required  to  have  two  levels  of  hus  mteitace  one  global  and  one  local.  I lie  Bll  devices  support  a 

distributed  round-robin  bus  protocol  scheme  with  message  broadcast  cupabiblv  io  multiple  Pis. 
I he  Bll-  contains  the  necessarv  hardware  to  associative!)  match  logical  input  mes  >gc 
identification  headers  and  automatical!)  vedm  these  messages  into  sottvvare-sc  lec table  PI 
memory  buffers.  Plus  data-vcctormg  teatuu-  relieves  the  pnucssoi  tnun  coutu-uaflv  setting  up 
and  servicing  the  Bll  hardware,  an  important  lesponse  time  tc.ituie  when  both  tin  local  and 
(dobal  buses  are  processing  messages.  Ihe  primal)  Bll  hardware  devices  lor  the  local  and 

(ilobal  buses  an.-  a common  design  with  signals  set  aside  on  the  dev  ice  to  serve  as  function- 

selection  pms.  i.e..  these  signals  dictate  the'  operation rec|uiic-d  !<•  make  the  device  function  as 
either  the  (ilobal  or  local  Bll  . and.  consequent!)  increase  the  use  ot  the  -.ante  common  devices, 

Multiple-device  partitioning  was  recommended  lot  the  BH’  hardwate  tuiicdoii.s.  Those 
devices  that  were  identified  included 

A bus  interface  logic  unit  (BILL)  that  is  lespotisible  Joi  interfacing  the  PI  to  a I DM 
bus 

A bus  interface  translation  unit  iBHI  » which  converts  serial  bt-pliase  to  parallel  NRZ 
data 

A redundant  bus  management  unit  <KBMl’>  which  is  iisc-d  to  implement  the  RBMl‘ 
function. 

5.  PE  I O Interface  Init 

Ihe  PI  lOll  provides  the  basic  PI  external  data  trail-lei  taulities.  mtemipt-inasking  and 
pnoritv -resolving  logic,  interval  tinier,  and  internal  PT  clock.  I wo  LSI  alternatives  were  identified 
for  these  IOll.’  (unctions.  One  approach  was  to  use  a single,  complex,  large-scale  integration 
device  to  implement  most  ot  the  IOll  (unctions.  An  alternate  approach  was  to  establish  a 
modular  family  of  devices  tor  the  IOll’  tuiKtions.  Ihis  Jamil)  included  the  following  pail  tvpes 

A two-device  autonomous  data  traiistcr  channel 

An  input  output  data  inter!  ice  device  to  provide  data  path  buffering  between  the  PI- 
I-Bf  ’S  and  i O data  lines 

An  I-BIS  master  interlace  dcvi.e  which  pert  ot  ms  l-Bl  S coiitiol  luiu  turns 

An  l-Bl’S  slave  interlace  device  usc-d  tor  passive  device  u-.g..  mentor)  i and  I BIS 
interface 

An  interrupt  interface-  device  which  piovidcs  mtcirupt  marking,  pnoritv.  and  control 
functions 

A programmable  interval  timer. 

6.  PE  Technology  and  Cost  Projection 

The  investigation  ot  candidate  implementation  technologies  and  the  derivation  «'•  a . ost 
projection  tor  the  DP  M considered  several  items,  ihe  examination  oi  I Si  technologies  revealed 
the  following  information 


Sovcial  high-dcv la'  density , low-power  I.SI  technologies  offer  the  necessary 
pei lormance  ami  m/c  characteristics  lor  DP/M  applications.  Prime  candidates 
include  NM<  *S.  II.  and  CMOS. 

I i '-  wide  operating  temperature  range  lor  military  applications  must  be  considered  in 
the  selection  ol  device  technology.  Avionic  equipment  using  the  DP/M  must 
operate  in  temperature  environments  that  can  vary  from  55 °C  to  +I00°C;  this 
implies  that  devices  inside  those  equipments  will  ex  pc'  -nee  temperatures  from 
5'"  to  * I ’5  ( 

technology  piodm dnlitv  aflects  device  yield  and.  eventually,  end-item  cost.  Ideally, 
the  technology  selected  for  the  DP  M should  be  used  for  high-volume  commercial 
production.  I his  would  allow  significant  cost  advantages  and  would  minimize  the 
problem  of  obtainin'.’  multiple  sources. 

Wins  possesses  the  best  per  formative  density  characteristics  of  the  presently  mature  LSI 
technologies,  however,  its  ability  to  operate  above  +‘Mf  C is  unclear.  Two  high-density,  low-power 
LSI  technologies  capable  ol  wide  operating  temperature  ranges  are  Integrated  Injection  Logic 
(lJLi  and  Complementary  MOS  (CMOS).  Both  technologies  offer  PI:  implementation  and  are 
capaole  ot  operating  over  a wide  temperature  range.  Additional  benefits  include  a natural 
tolerance  ot  power-supply  voltage  variations  ami  potential  candidacy  for  nuclear  radiation 
hardening.  While  l:  I is  a nevvei  technology,  its  bipolar  technology  characteristics  have  the 
potential  tor  paralleling  the  I I I 5 too  “-400  device  family  where  the  same  manufacturing 
processes  can  be  used  to  make  both  military  as  well  as  commercial  temperature  range  parts.  The 
manufacturing  process  tor  l:  I waters  appears  to  have  fewer  steps  than  CMOS,  and  l:  L offers  a 
40-percent  dev  ice-density  improvement  over  CMOS. 

\ partitioning  of  functions  and  an  estimate  of  the  device  complexity  of  the  DP/M  PL  was 
derived  and  the  results  are  summarized  in  I able  I.  These  data  were  the  basis  for  a cost 
projection  h.r  the  IM  in  the  l‘*X0  time  period.  A commercial  grade  lO’C  to  +70°C|  DP/M  PL 
was  estimated  to  cost  approximately  S550  in  quantities  of  5.000.  while  the  military  grade 
equivalent  was  estimated  to  cost  SI. "45.  Both  estimates  offer  significant  improvement  overtire 
current  costs  associated  with  avionic  processors.  The  large  variant  in  cost  for  a military egrade 
Component  is  associated  with  the  additional  operating  temperature  range,  hermetic  package, 
inspection,  burn-in.  testing,  and  reliability  requirements  imposed  by  military  specifications  on 
components. 

7.  hxccutive  Software 

I lie  executive  Milt  ware  design  effort  resulted  in  the  detailed  functional  specification  of  a 
two  level  control  structure.  A set  of  common  routines  was  defined  for  the  Global  Hxccutive 
• (■I  Xi  and  Local  Lxecutivc  tl  I.X)  functions.  The  ( >1  X is  responsible  for  system  scheduling  and 
mode  control  and  the  Local  I xeculive  ll.I.Xt  provides  the  necessary  control  function  for  tasks 
assigned  to  a given  PI  . The  organization  of  both  executives  is  based  upon  a table-driven  control 
structure  philosophy  to  permit  their  use  and  adaptation  in  different  PH  network  configurations. 
Detailed  simulation  models  of  major  (il  X and  LI  X routines  were  developed  and  incorporated 
into  the  SNZ.. 
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TABLE  t.  DP/M  PE  COMPLEXITY  ESTIMATE* 


Functional  Unit 

Complexity 

(gates/biu) 

(XiOOO) 

Packages 
Type  Total 

Pi»* /Package 

Power 

(watt*) 

Processor 

3 to  4 

1 to  2 

1 to  2 

48 

0.7 

Memory  controller 

0.6  to  0.6 

1 

1 

48 

0.2 

Memory 

128  to  132 

1 

8 to  q 

20 

3.2 

Bus  interface 

4 to  5 

3 

8 

14.  20.  48 

1.7 

10  interlace 

! to  t.5 

2 to  6 

6 to  q 

16.  18.  24.  28.  40.  48 

i.q  m 2.i 

Note.  See  Section  VI  tor  additional  backj  r.iuml  data. 

K.  Process  Construction  Study 

The  process  construction  study  addressed  the  requirements  and  defined  a methodology  to 
be  used  in  designing  real-time  software  lor  DP  M.  The  structure  and  characteristics  of  software 
for  a distributed  network  of  PKs  were  examined  and  representations  of  these  processes  were 
identified.  These  struct  .res  include: 

the  data  tlow  graph 

the  control  tlow  graph 

the  program  directed  graph 

the  maximaHy-paralie!  predecessor  successor  graph. 

A procedure  was  defined  for  real-time  system  software  design,  development,  and  validation  that 
uses  successive  levels  of  model  development  ant!  four  levels  of  simulation,  including: 

system  network  simulation 

functional  simulation 

instruction  level  simulation 

analytic  hybrid  simulation. 

Three  levels  of  process  construction  were  identified,  the  Basic  Process  Constructor,  the 
intermediate  Process  Constructor,  and  the  Production  Process  Constructor.  The  emphasis  of  the 
DP  M design  effort  was  on  the  specification  of  requirements  for  the  Basic  Process  Constructor. 
Nine  basic  steps  were  identified  in  the  Basic  Process  Constructor,  and  appropriate  algorithms 
were  identified  for  each  step.  Certain  procedures  were  amenable  to  automated  techniques  and.  as 
time  permitted,  analysis  programs  were  written  for  the  following  functions: 

A topological  sort  that  analyzes  the  input  output  precedence  relations  between  tasks  of 
a program  model  and  generates  identification  numbers  for  all  program  tasks. 

A path  matrix  constructor  that  analyzes  the  structure  of  program  task  graphs  and 
forms  a matrix  of  task  interrelationship 

An  execution  path  generator  which  constructs  all  alternative  execution  paths 
throughout  a program. 
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Data  poulticed  l'>  Iti  preceding  programs  were  used  t«»  generate  Di*  M 14  execution  time  and 
memory  stoi  (*•••  le  imrements  !•  »i  avionic  mi'sMii  soitware  model'  and  to  verify  t tie  proper 
ore.im/ation  < *t  the  sottwue  modeN  Meoiitluns  toi  allocation  ol  avionic  sot  (ware  to  the  PL 
network.  based  on  inteeei  ptoei  iniiinne.  .Jii'tei  analysts.  and  a heini'tic  method  were  identified 
and  the.r  v h tt a<.  teH'tics  I'lsai'sed. 

\ !mi'  liou.il  specific  ition  oi  the  recommended  I *1*  M process  construction  procedure  was 
• le?':*e>!  u.d  mJmie.i 

l*!o,c"  oii'tuution  ileoi'ihni' 

i 'utput  Uaia  ' •» 

He  I . ! sx.i  n>d  'oil  -i  • iifl'1  i"  ■»>{  iti<  <n  requirement' 

I"  earn  an  insuthi  into  (he  » -.•* | « meui'-i: t"  oi  !>i’  \1  process  construction.  a limned  case  study  was 
peiJoo;  i ompnten/ed  methods  were  used  ti>  estimate  mission  soitware  execution  time  and 
ii,'.‘"loi,1  te-iuiit"  ent'  oi,  the  1)1’  \!  1*1  md  to  manipulate  a data  base  oi  bus  and  I O signals  A 
'U':. try  o;  '(.is  > i'C  'tin's  >■  m I nie.l  in  X;  '''■»  tion  l\.l)  and  \ppemlix  B. 

4.  fault  loleraiuv  \nalysis  \etivilirs 

I lie  i ole  oi  |)P  M with  re  .pec  t to  tault  tolerance  .r.  an  avionic  system  was  examined. 
Seveial  key  observations  wet--  made  I he  expected  reliability  it  LSI  DP  M devices  when 
compat.d  to  the  typical  failure  rate'  ot  avion**  sensor'  is  qui‘e  high  and.  consequently.  DP  M is 
not  expected  to  he  a source'  ot  tault'  when  deployed  tn  avionic  systems,  fhe  DP  M is  amenable 
to  physical  ami  timctional  avionic  tault-tolerance  techniques.  Physical  fault  tolerance  is 
achievable  via  redundancy  techniques  Mich  as  those  used  in  fly-by-wire  flight-control  systems. 
I uric  tional  tault  tolerance  mJudc'  software  techniques  for  achieving  degraded  modes  of 
operation  once  an  ertor  has  been  detected,  features  have  been  included  in  the  PL  processor. 
Hi l and  memory  to  aid  in  error  detection  and  recovery  activities.  Hie  power  supply 
requirements  and  transient  conditions  are  known  in  an  avionics  environment,  and  the  use  of  an 
ultra-reliable  power  source  toi  DP  V u'  been  investigated. 

C.  REPORT  OVERVIEW 

Subsequent  sections  ot  this  t.por!  di'ctiss  the  following  topics: 

System  design  • or.snlcr ilioti' 

Intormation  ti  Ulster  busine  system  design 
Processor  memory  dcsnrn 
I xternal  if  0»  device  interface 
PI  implementation  considerations 
I unctioiul  simulation  system 
I xecutive  design  and  system  opeution 
Process  construction  study 
I aiilt  tolerance  analysis. 


SECTION  II 

SYSTEM  DESIGN  CONSIDERATIONS 


This  section  discusses  the  basic  considerations  used  to  derive  the  functional  design  of  the 
DP'M  system  modules.  As  such,  it  is  intended  to  provide  a high-level  overview  of  those  thoughts 
that  influenced  the  design  process  throughout  the  DP/M  program.  A review  of  the  system 
configurations  for  DP'M  is  presented,  and  an  overview  of  the  DP/M  system  communication 
approach  and  a review  of  design  alternatives  conclude  the  section. 

A.  DESIGN  CONCEPTS 

The  task  addressed  during  the  DP'M  program  was  to  specify  a functional  detailed  design  for 
the  DP/M  hardware  ana  produce  a set  of  flexible  software  simulation/analysis  tools.  This  Jesign 
was  to  be  based  upon  those  avionic  requirements  identified  in  previous  Air  Force  studied  For 
the  DP'M  design  effort,  a set  of  concept,  was  identified  and  served  as  guidelines  throughout  the 
design  process.  These  guidelines  were  by  necessity  general  in  nature,  but  their  purpose  was  to 
ensure  that  the  output  of  the  DP/M  design  was  as  applicable  as  possible  to  projected  Air  Force 
requirements. 

1.  All-Semiconductor  Design  Concept 

One  of  the  original  DP'M  concepts  was  the  eventual  realization  of  an  all-semiconductor 
design,  and  distributed  dedicated  processor  /memory  pairs  lends  itself  to  an  all-temiconductor 
implementation.  A major  advantage  of  this  concept  is  the  use  of  LSI  technology  for  the 
1978-80  time  period  for  a DP/M  system.  Projections  as  to  the  practicality  and  cost  effectiveness 
of  LSI  vary:  however,  trends  in  the  early  and  middle  1970’s  indicate  LSI  manufacturing 
techniques  are  maturing  and  that  LSI  semiconductor  devices  are  being  economically  produced. 
Historically,  memory  devices  have  been  the  leader  in  LSI  device  production  due  to  their  large 
commercial  market  demand.  An  encouraging  feature  of  the  1973  and  1974  semiconductor 
product  lines  was  a variety  of  LSI  logic  functions  such  as  4-  and  8-bit  microprocessor  chip  sets. 
The  commercial  market  availability  of  such  memory  and  logic  devices  gives  a continued 
indication  that  an  all-LSI  DP/M  for  the  1978-80  time  frame  is  indeed  feasible. 

2.  Architecture  Selection  Concept 

The  basic  organization  of  the  DP/M  processing  element  (PE)  lias  been  established  in 
previous  AFAL  sponsored  work  and  was  shown  in  Figure  1.  Several  thoughts  guided  the  actual 
design  specification  of  the  PE  processor,  memory,  and  Bus  Interface  Unit  modules. 

The  processor  module  will  quite  likely  be  a one-  or  two-chip  LSI  central  processing  unit 
(CPU)  device  in  the  DP/M  time  frame.  Present  semiconductor  LSI  chip  sets  offer  a variety  of  4-, 
8-,  and  12-bit  microprocessor  or  microcomputer  architectures  while  16-bit  microcomputers  are 
projected  for  1975.  These  choices  in  the  data  path  bit  width  of  the  processor  architecture  are 
the  result  of  current  market  demands  and  the  present  state  of  LSI  technology  manufacturing 
processes.  Several  previous  Air  Force  studies  have  recommended  that  a large  portion  of  the 
avionic  processing  problem  space  can  be  solved  with  a 16-bit  computer  architecture.  This  16-bit 
data-processing  organization  also  parallels  the  wide  number  of  available  commercial  16-bit 


mim-computcis  and  their  planned  "micro  equivalents”  and  is  the  must  likely  and  predominant 
organization  ot"  micro-class  computers  tor  the  DP  M time  period.  The  goal  of  the  DP  M processor 
design  was  to  produce  a detailed  specification  and  simulation  program  model  that  would  be 
applicable  to  a number  of  avionics  computational  problems.  Now  that  this  design  has  been 
completed.  \l  AL  has  both  a design  and  the  detailed  simulation  tools  that  can  serve  as  a 
departure  point  suitable  lor  evaluating  ditterent  processor  architecture  alternatives. 

I he  semiconductor  nature  ot  the  DP  M had  an  impact  on  the  Pf  and  its  memory  design. 

I he  primary  concern  was  the  volatility  ot  semiconductor  memories  ti.e..  loss  of  data  when  power 
is  removed!.  The  three  candidate  solutions  to  this  problem  are:  < lithe  use  of  a non-volatile 
memory  device  such  as  MNOS.  t2ithe  use-  ot  a reliable  and  continuous  DP  M power  source,  or 
*3 1 the  use  ot  non-volatile  lived  memory  dev  ice  such  as  Read  Only  Memories  ( ROMs).  The  goal 
of  the  DP  M functional  design  was  to  investigate  candidate  solutions  to  this  problem  and  to 
ensure  that  the  PI  functional  architecture  did  not  restrict  the  use  of  different  memory 
technologies. 

I he  BIT  module  was  the  key  component  used  to  build  a network  of  distributed  Pts.  The 
specification  ot  its  organization  had  to  consider  such  items  as  expandability,  efficiency,  and  fault 
detection.  The  dual-level  globjl  local  nature  of  the  DP  M bus  philosophy  is  the  primary  means  of 
expanding  the  processing  power  ot  the  DP  M and  building  different  network  configurations,  fcach 
PP  ic  capable  ot  having  this  dual-level  bus  interface  and.  as  such,  the  BIT  represented  one  of  the 
more  common  and  potentially  complex  hardware  modules.  It  was  recognized  that  the  servicing 
of  input  output  message  transfers  by  the  processor  via  the  BIT  must  be  efficient  ti.e..  minimize 
processor  throughput  degradation ).  The  Mil's  role  as  the  primary  inter-PP.  communication  path 
also  dictated  that  the  design  allow  lor  fault  detection  and  recovery  mechanisms  within  the  DP  M 
network. 

3.  Compatibility  Concept 

Die  DP  M program  recognized  that  its  system  design  must  be  cognizant  of  and  compatible 
with  \ir  force  standards  that  would  be  applicable  in  the  l‘>7X  1^X0  avionics  time  frame.  While 
it  is  admittedly  difficult  to  project  the  e .act  natua*  of  future  avionic  systems  and  Air  Force 
standards  tor  components  in  these  systems,  such  present  standards  as  those  for  environmental 
and  electrical  power  interlace  were  considered  in  the  DP  M system  design.  It  was  the  aim  of  the 
stem  design  that  evolving  testing  and  maintainability  philosophies  for  Air  Force  equipment 
should  be  encouraged  by  use  ot  DP  M system  components.  This  emphasis  on  compatibility  with 
Air  Force  standards  also  dictated  that  methods  should  be  identified  during  the  design  to 
encourage  compliance  with  these  specifications. 

Consider,  lor  example,  the  accepted  way  in  which  parts  are  currently  selected  for  use  in 
electronic  equipment.  The  continued  evolution  of  microcircuit  technology  has  resulted  in  the  use 
of  the  Approved  Parts  last  typified  by  MIL-STD-TH  and  stringent  integrated  circuit  standards 
such  as  MIL-M-3K5IO  or  MIL-SID-KX3  to  guide  militarized  equipment  parts  selection.  The  intent 
of  these  specifications  is  to  offer  a common  sol  of  approved  parts  manufactured  and  inspected  to 
the  Ciovemmcnt's  satisfaction  and  to  logistically  reduce  a potential  proliferation  of  nearly 
identical  part  types.  In  its  early  stages,  this  approach  was  well  accepted  by  both  the 
semiconductor  manufacturers  and  militarized-equipment  designers.  However,  trends  such  as  the 
one  shown  in  figure  2 indicate  that  military  demands  on  microcircuit  technology  are  being 
diminished  when  compared  to  non-military  users.  As  the  capacity  of  semiconductor 


Figure  2.  Ui.  Electronics  iMtetry  Treads 


manufacturers  is  absorbed  by  the  larger  dollar  non-military  markets,  certain  items  on  the 
Approved  Parts  List  (APL)  are  iiscontinued  if  their  production  demand  cannot  keep  pace  with 
the  sales  of  non-APL  devices.  Ideally,  the  most  desirable  solution  would  be  parts  that  could 
satisfy  both  military'  and  non-military  specifications,  thereby  creating  a sufficiently  large  demand 
for  more  production  of  such  “dual-purpose”  devices.  Likewise,  a military  specification  part  that 
is  usable  in  a sufficient  number  of  different  military  applications  can  create  a suitable  demand 
for  high-volume  production.  The  DP/M  concept  has  the  potential  to  fulfill  this  multiple- 
application  requirement  with  its  low-cost  LSI  PE  modules,  it  was  the  goal  of  the  DP/M  design 
effort  to  identify  ways  in  which  these  compatibility  concepts  can  be  encouraged. 

4.  Usability  Concept 

A continued  emphasis  on  usability  dominated  the  design  activity,  as  did  the  consideration 
given  to  eventual  DP/M  deployment  in  avionic  systems.  As  the  expected  costs  of  the  DP/M 
hardware  decrease,  the  total  life  cycle  costs  associated  with  using  the  DP/M  in  system  design, 
development,  test  and  evaluation  fDDT&E)  as  well  as  field  deployment  will  be  magnified  by 
comparisor.  An  obvious  non-military  parallel  exists  today  when  one  considers  the  labor  cost  of 
design  engineering  as  compared  to  commercial  minicomputers  that  can  be  purchased  for  $1,500 
to  $3,000.  The  use  of  the  system  fits  design,  check-out,  and  maintenance!  clearly  dominates  the 
cost  of  the  hardware.  The  concept  of  a usable  DP/M  system  influenced  each  phase  of  the 
hardware  and  software  design. 
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Applying  thii.  concept  ot  usability  influenced  the  functional  simulator  design  effort  a-  wel' 
a>  the  process  construction  study  and  functional  hardware  definition.  To  he  useful,  the  System 
Network  Simulator  structure  had  to  he  flexible  at.d  allow  for  a variable  number  of  topologically 
interconnected  Pis  to  interact  ever  1 DM  buses,  'Ih**  usefulness  of  the  network  level  hardware 
model  was  to  be  complemented  by  a more  detailed  PE  simulator.  The  goal  of  the  PH.  simulation 
was  to  allow  detailed  -valuation  of  the  PI-  while  executing  programs,  transferring  serial  bus  data, 
and  transferring  1 O data.  I urthermore.  this  functional  simulation  system  had  to  be  suitable  for  a 
variety  ot  paper  analytical  dtsign  studies,  fills  dual-level  simulation  capability  was  to  be  further 
used  bv  being  incorporated  by  the  process  construction  activity  in  specifying  a method  for  the 
l)P  M Process  ( onstructor. 

I sabilitv  also  influeireed  the  PI  hardware  design.  With  respect  to  the  DP/M  hardware,  it 
quickly  translates  to  “how  easily  ..an  I apply  this  hardware  to  different  applications"  and  “how- 
can  I test  and  check-out  my  design."  Ibis  emphasis  on  testability,  fault  isolation,  and  simplified 
maintenance  concepts  was  to  guide  the  design  effort  and  to  ensure  a usable  DP/M  design  was 
produced. 

5.  Modularity  Concept 

Ihe  concept  of  modularity  was  another  key  design  consideration  for  DPM.  Modularity 
influenced  the  ease  of  system  application  and  eventual  system  cost.  Consider,  for  example,  the 
DP  M PH.  A specification  of  too  high  a level  of  integration  of  PH  .unctions  in  one  LSI  device 
can  potentially  complicate  the  hardware  implementation  while  at  the  same  time  reduce 
manufacturing  yield  and  increase  per-unit  cost.  A futher  disadvantage  is  possible  in  that  the 
application  ot  the  device  in  other  systems  can  he  often  limited  because  of  its  special-purpose 
design.  In  contrast,  a simple  approach  using  low  levels  of  integration  can  cause  an  explosion  of 
part  types  that  complicate  system  design  and  increase  physical  size  and  logistic  problems. 
I'nfort unate ly.  opinions  as  to  the  ideal  level  of  the  modularity  will  differ  with  each  application 
and  system  designer.  F or  the  l)P  M design,  the  general  concept  was  that  functions  should  be 
implemented  with  modules  which  will  allow  for  reasonable  incremental  growth  with  respect  to 
capability. 

One  recognized  method  ot  encouraging  modularity  is  the  use  of  a standard  interface.  A 
standard  interface  can  be  used  to  allow  incremental  growth  and  expansion  capability  as  well  as 
to  provid  • an  orderly  method  of  technology  involvement  for  the  different  DP/M  system  modules. 
Ihe  interlace  Mgnafs  -nd  me’htxl  remain  constant  and  allow  different  technologies  to  be  used, 
providin.  the;  meet  these  mterf-.e  requirements.  Standards  like  ARJNC  and  HA  have  long  used 
such  methods  to  provide  growth  and  technological  evolvement  for  their  respective  system 
components. 


fo  a decree,  modu/iri'y  w-us  recognized  to  affect  the  application  and  use  of  all  avionic 
components.  To  illustrate.  .he  choice  of  processing  growth  alternatives  was  found  to  be  in 
$I00,(X)0  increments  and  40-pourJ  boxes,  this  “coarse”  level  of  modularity  negates  its  wide 
application.  However,  if  the  cost  and  size  of  incremental  growth  an-  expansion  were  similar  to 
that  envisioned  for  LSI  DP/M  uevices.  the  avionics  architect  has  a large  degree  of  flexibility  in 
applying  ■ iore  computerized  resources  to  his  pioblem.  This  wide  use  of  the  same  common 
module*  has  other  important  benefits,  all  centered  around  the  idea  of  replication.  Electronic- 
equipment  and  semiconductor  manufacturers  such  as  Texas  Instruments  use  this  high  level  of 
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Figure  3.  Modularity  Leaning  Curve  Effects 


replication  of  a common  component  (or  process)  to  lower  the  acquisition  cost  of  a module  to  a 
system  user.  The  benefits  of  maximizing  the  modularity  of  an  equipment  can  be  shown  by  a 
quick  look  at  the  effects  of  learning  curves  on  modularity  and  replication  on  cost. 

Figure  3 shows  a family  of  learning  curves  and  the  regions  on  these  curves  where 
production  avionic  and  weapon  systems  may  falL  A learning  curve  is  based  on  the  historical  fact 
that  when  production  increases,  cost  decreases.  A 95-percent  curve  implies  that  when  production 
doubles,  the  unit  cost  decreases  by  5 percent  The  figure  shows  95-.  85-.  and  75-percent  curves. 
Historically,  a slope  of  95  percent  is  achievable  by  worker  training,  tooling,  and  manufacturing 
flow  improvement.  A slope  of  85  percent  is  achievable  through  automation,  and  75  percent  is 
achievable  only  through  basic  process  improvement,  product  evolution  and  yield  improvement. 
Production  of  most  military'  equipment  typically  falls  in  the  95-  to  85-percent  region  and 
frequently  does  not  even  achieve  that  level  because  of  insufficient  firm  volume  levels  to  justify 
automation  and  because  of  broken  production  lots,  due  to  funding  phases,  which  necessitate 
employee  reassignment. 

Examining  the  curve  shows  the  potential  \alue  of  modularization  with  DP/M  technology.  A 
typical  nonmodular  design  might  have  a total  production  varying  from  a few  thousand  to  as 
many  as  50,000  units,  if  several  systems  use  the  same  modules,  total  production  could  approach 
several  hundred  thousand  units.  Further,  the  broader  application  base  lessens  the  risk  of 
automation  investment  and  allows  sooner  entry  into  the  85-percent  total  inventory  requirements, 
and  AGF.  and  training  costs  are  reduced. 
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The  greatest  reduction  in  cost  will  be  achieved  only  if  the  slope  of  the  learning  curve  can  go 
lower  than  85  percent.  The  question  is,  can  it  and,  if  so,  how?  The  cost  curves  for  digital 
integrated  circuits,  over  the  past  several  years,  have  displayed  75  percent  or  better  slope.  The 
reason  is  essentially  that  of  “modularity.”  Almost  ail  digital  equipment  uses  a few  basic  families 
of  devices.  This  standardization  has  resulted  in  the  volume  base  to  achieve  cost  improvement. 
Notice  that  standardization  has  not  implied  stagnation.  The  number  of  devices  in  a given  line 
increases  almost  daily  and  different  packaging  and  screening  processes  yield  devices  for  both 
severe  and  nonsevere  environments.  All  devices,  however,  use  the  same  processes  and  the  “shared 
experience”  results  in  lower  unit  cost  for  each  member  of  the  family. 

it  is  this  same  goal  of  maximum  modularity  and  applicability  that  was  considered  during 
the  DP'M  hardware  and  software  design. 

B.  SYSTEM  APPLICATIONS 

The  projected  size,  weight,  and  minicomputer-like  computation  capabilities  of  the  DP/M 
modules  permit  their  use  in  several  avionic  applications.  Candidate  applications  were  identified  in 
which  DP/M  modules  could  be  used,  and  each  role  was  examined  for  the  requirements  it  would 
impose  on  the  DP  M deMgn.  Consideration  was  given  to  the  type:  of  computation  (arithmetic, 
logical  data  manipulation  I,  algorithm  execution  time  constraints,  and  special  deployment 
requirements  such  as  maintenance  and  testing  features.  This  requirement  search  was  by  necessity 
brief,  but  it  identified  potential  applications  and  emphasized  a set  of  requirements  for  the  DP'M 
design.  The  three  roles  considered  for  the  DP'M  were: 

The  stand-alone  computation  unit 

The  stria*  sensor  or  standard  interface  unit 

The  distributed  function  configuration. 

1.  Stand-Alone  Computation  Unit 

The  stand-alone  DP'M  configuration  is  a classical  uniprocessor  architecture  where  the  PI: 
processor,  memory,  and  I O modules  are  deployed  as  a limited-capability  microcomputer. 
Current  avionic  equipment  using  such  microcomputers  includes  radio  and  TACAN  navigation 
sets,  digital  air  data  computers,  and  aircraft  ground  proximity  warning  systems.  Algorithms  for 
these  functions  such  as  the  air  data  equations  are  straight-forward,  and  until  recently  have  been 
primarily  implemented  using  either  mechanical  or  analog  techniques.  The  projected  cost  and  size 
of  DP'M-like  modules  open  up  several  new  applications  including  missile  digital  autopilots, 
control  and  display  logic  controllers,  and  built-in  test  (BITt  and  diagnostic  sequencers.  This  use 
of  a few  LSI  devices  to  add  self-diagnosis,  test,  and  maintenance  capabilities  offers  a significant 
potential  in  reducing  future  maintenance  costs  of  avionic  equipments. 

2.  Smart  Sensor  or  Standard  Interface  Unit 

A natural  followon  to  the  stand-alone  configuration  is  the  use  of  DP/M  module  to 
pre-process  data  within  a sensor  and  provide  a standard  interface  to  other  avionic  equipments.  In 
the  preprocessor  role,  data  is  converted  to  a common  format  for  use  by  other  avionic  system 
elements.  A review  of  some  examples  found  in  previous  avionic  study  efforts  will  highlight  the 
requirements  within  this  application,  and  these  requirements  typify  the  operations  normally 
found  in  avionic  computation. 
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The  present  DAIS  (Digital  Avionics  information  System)  concept  is  taking  one  step  of 
providing  a standard  interface  by  converting  all  avionic  subsystem  signals  into  a digital  format 
within  a remote  terminal,  and  transmitting  these  converted  signals  over  a multiplexed  data  bus  to 
the  DAIS  processors.  In  its  present  form,  the  remote  terminal  converts  and.  in  some  instances, 
packs  this  signal  data,  but  does  not  attempt  to  preprocess  the  data  for  digestion  by  the  DAIS 
computers.  An  examination  of  the  DAIS  sensor  signal  list  shows  data  types  that  include  discretes 
(to  be  packed/unpacked  I.  binary  I's  and  2’s  complement  data,  weighted  or  scaled  binary  (e.g.. 

I hit  equals  1.5  degrees),  and  binary  coded  decimal  (BCD).  The  core  processors  accept  this  data 
from  the  remote  terminal  and  perform  the  packing/unpacking  and  conversion  to  the  proper 
format  (predominantly  floating  point)  for  use  by  the  different  avionics  programs.  This  requires 
executive  software  activity  to  schedule  this  task  as  well  as  computational  resources  to  perform 
(he  conversion.  The  use  of  an  inexpensive  DP/M  PF.  to  assist  the  relatively  more  complex  and 
expensive  DAIS  computing  resource  offers  a cost-effective  method  of  system  growth  and 
expansion. 

Examples  of  DAiS-like  avionic  subsystems  that  require  preprocessing  include  the  Loran 
receiver  and  the  weapon  station.  The  examined  Loran  receiver  outputs  two  26-bit  time-difference 
quantities  represented  as  six  4-bit  BCD  characters  plus  two  status  bits.  These  data  must  be 
decoded  and  converted  into  a format  suitabL  for  use  by  the  Loran  navigation  algorithms. 
Likewise,  the  receiver  expects  from  the  computer  binary  velocity  aiding  information  made  up  cl' 

I I data  bits,  sign  bit.  and  two  status  bits,  all  in  one's  complement  form,  while  other  outputs  are 
BCD  encoded.  While  the  information  formatting  is  not  complicated,  it  is  well  suited  to 
preprocessing  by  DP/M-like  microprocessors.  Another  example  of  a subsystem  using  BCD  data 
inputs  is  the  DAIS  hot  bench  weapon  station  in  which  weapon  count  and  station  identification 
jre  lo  be  transferred  in  this  coding  scheme. 

One  example  of  j demanding  preproc.  • ;"e  function  is  associated  with  extracting  data  from 
sy  nchros  and  resolvers.  Usually,  these  devices  output  two  numbers  that  represent  the  magnitude 
of  the  sine  and  cosine  of  an  angle.  To  determine  the  actual  angle  for  use  by  different  avionic 
subfunctions,  the  quotient  of  the  sine  and  cosine  can  he  formed  to  determine  the  tangent,  and 
then  the  arctangent  of  this  number  is  taken  to  determine  the  angle.  This  processing  is  obviously 
more  mathematically  complex  than  the  first  example  but  still  well  within  the  capabilities  of  a 
DP  M PT. 

A similar  potential  application  was  identified  by  examining  an  existing  airborne  emitter 
location  system  that  interfaced  with  an  inertial  navigation  subsystem.  The  heart  of  the  system 
used  a high-speed  digital  precessor  for  Hostile  threat  classification,  prioritization,  and  locatior 
calculations.  The  inertial  navigation  subsystem  was  used  to  supply  aircraft  roll,  pitch,  and  yaw 
data  as  well  as  velocity  north  and  velocity  east  information.  This  information  was  sampled  by 
the  digital  processor  at  data  rates  of  5 and  25  Hz.  and  its  processing  was  a high-priority  task  to 
be  performed,  hath  data  item  was  input  as  a 1 6-bit  word  in  the  format  shown  in  Figure  4. 
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Figure  4.  Example  Data  input 
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Processing  of  the  data  included  extracting  the  hardware  status  hits,  scaling  the  remaining 
sine  and  cosine,  computing  the  square  root  of  the  sum  of  the  squares  of  the  sine  and  cosine, 
checking  the  result  for  a value  within  proper  limits  and  normalizing  the  result  if  necessary.  Other 
operations  included  validity  checking  of  computed  results.  While  the  computation  associated  with 
these  operations  again  is  not  difficult,  there  is  a potential  sacrifice  of  processing  devoted  to 
threat  classification  and  location  calculations  when  overhead  is  devoted  to  input  preprocessing.  In 
a dense  environment  of  hostile  emitters,  this  could  result  in  less  than  maximum  capability  system 
performance.  Once  again.  DP  M-liko  microcomputers  could  offer  an  economical  alternative  to 
multiprogramming  the  larger  and  faster  main  processor  hy  having  cu. rent  data  available  in  the 
proper  formal  and  at  the  proper  time. 

It  follows  that  the  next  generation  of  sensors  will  most  lik-ly  include  some  type  of 
programmable  logic  unit  that  can  provide  data  in  a standard  format  suitable  for  use  hy  a given 
application  system.  The  DP/M  PH  design  offers  this  capability  to  the  avionic  system  architect. 

Benefits  obtainable  with  this  smart  sensor  approach  include  a standardized  and  flexible 
peripheral  interface  that  has  the  potential  to  improve  reliability  while  minimizing  the  impact  on 
system  cost.  The  primary  advantage  is  the  establishment  of  a simplified,  programmable  data 
communication  interface  that  permits  orderly  growth  and  a natural  distribution  of  processing 
within  the  system.  In  addition,  this  type  of  dedicated  low-cost  processing  offers  the  potential  to 
simplify  check-out  and  maintenance  of  avionic  functions  hy  adding  computation  intelligence  in 
the  sensor. 

This  u“*  the  DP/M  PE  also  has  another  benefit  in  that  the  addition  of  a set  of  LSI  chips 
to  the  pen  >heral  c^nonents  can  significantly  increase  the  usability  of  the  device  while  not 
degrading  its  reliability.  Reliability  is  a key  factor  in  avionic  system  design  si'ice  a reduction  in 
reliabiP.y  implies  more  failures  can  occur.  Each  failure  requires  a maintenance  action  which  in 
turn  in.  reases  the  overall  system  life  cycle  cost  to  the  Air  Force. 

Proiection  of  the  MTBF  of  DP'M-like  LSI  chips  can  be  made  to  emphasize  this  point.  A 
previous  Air  Force  study  made  a rough  prediction  based  on  rules  typified  in  RADC-TR-69-350. 
“Failure  Rate  Prediction  for  Complex  Bipolar  Microcircuits.”  Using  extrapolation  techniques 
similar  to  those  described  in  this  report,  the  failure  rates  of  electrically  stressed  militarized  LSI 
chips  with  as  many  as  4.000  gates  was  estimated  to  he  on  the  order  of  magnitude  of  0.02 
percent  per  1000  hours.  This  ratio  implies  each  device  would  have  a calculated  MTBF  of  five 
million  hours.  When  compared  to  the  predicted  MTBFs  of  sensors  such  as  gyros  and  air  data 
sensors  that  range  roughly  from  one  to  10.000  hours,  it  is  obvious  that  the  addition  of  a few' 
high-density  LSI  devices  to  the  sensor  peripheral  will  have  a negligible  impact  on  failure  rates. 

3.  Distributed  Function  Configuration 

The  third  application  of  the  l)P/M  components  is  in  an  interconnected  network  of  PEs  via 
ID*!  hii\.*s  that  operate  as  a distributed  (unction  processing  system.  A block  diagram  of  a 
general  i/.'/M  system  configuration  is  shown  in  Figure  5.  This  figure  is  not  intended  to  depict 
any  particular  DP'M  network  but  instead  shows  interconnection  ot  major  components. 

Aircraft  sensors  and  actuators  communicate  with  a given  DP/M  PE  via  a digital  interface 
unit.  Input/output  between  the  PF  and  external  device  is  in  a digital  format,  with  external  signal 
conversion  for  the  sensor/actuator  at  the  digital  interface.  For  the  general  case,  the  DP/M  system 
functions  as  a federated  and  “dedicated  at  the  sensor”  processing  system.  Those  PEs  and  Affinity 


Groups  that  arc  not  required  to  interface  to  the  aircraft  sensor /actuatoi  system  function 
independently  and  communicate  over  the  Global  bus  system.  The  distributed  nature  of  DP'M 
also  permits  geographic  separation  of  I’!  s and  Affimt)  Groups  throughout  the  airframe. 

C.  OVERVIEW  OF  SYSTEM  COMMUNK ATION  INTERCONNECTION 
FACILITIES  DESIGN 

Tlie  DP  M system  interconnection  and  communication  facility  design  reflects  a multi-level' 
multi-functional  data-transfer  philosophy  which  supports  digital  data  communications  at  two 
basically  distinct  interface  levels-  1 1 1 inter-Pl  ti.e..  intra-DP  M system).  and  (2)  PF-to-cxternal 
device  (i.e..  between  the  DP  M system  and  external  aircraft  subsystem  equipments).  This  chosen 
approach  segregates  mter-PI.  or  inter-program  information  exchange  from  “input  output”  (DO) 
data  transfers  between  PFs  and  external  devices,  as  shown  in  Figure  b.  The  two  interface 
facilities  are  different  in  function  and  operation  and  represent  a “best-fit”  approach  V~ 
functionally  independent  interface  requirements  while  also  maximizing  system  hardware 
efficiency  and  simplicity.  I his  approach  was  formulated  from  rationale  discussed  in  the  following 
paragraphs. 

The  primary  alternative  addressed  in  the  DP  M communications  structure  design  dealt  with 
the  method  of  communicating  between  Pi  s (programs)  and  external  I'O  devices.  In  essence,  the 
basic  choices  were  to  either  make  each  1 O device  directly  accessible  to  all  or  a subset  of  PFs 
(e.g..  via  a common  busing  arrangement)  or  allow  direct  communication  between  Pi  s and  I/O 
devices  on  an  exclusive  one-to-one  basis.  The  latter  (chosen)  approach  ha*,  one  apparent 


DIGITAL 

INTERFACE 


1 

A C 

SENSORS 

ACTUATORS 


DIGITAL 

INTERFACE 

a 

a 

A C 

SENSORS 

ACTUATORS 


DP  M 
SYSTEM 


Figure  5.  General  DP/M  System  Network  Configuration 


Figure  6.  Syslem  interconnection  and  Communication  Structure  (Example) 


disadvantage  with  respect  to  the  tormcr  approach.  the  disadvantage  is  due  to  the  etteetive 
dedieating  ot  devices  to  single  1*1  s which  may  perhaps  affect  !>oth  system-level  functionality  and 
reliability.  However,  this  apparent  disadvantage  is  somewhat,  it  not  completely,  relieved  because 
the  de.ice  can  become  accessible  to  all  members  ot  the  1)1* 'M  system  (including  other  external 
devices  as  well  as  1*1  % I indirectly  via  the  1*1  to  which  it  is  physically  attached.  I ach  PI'  is 
connected  to  all  other  system  Pis  via  the  (ilobal  bus.  I he  PI.  then,  becomes  a "Hus  Interlace 
l nit"  by  which  all  I ()  data  to  trom  a particular  external  device  is  routed  within  the  integrated 
avionic*  mtormation  system. 

I Ins  I O approach  not  only  otters  functional  equivalence  with  the  alternate  approach,  but 
also  reduces  system  hardware  complexity.  I xternal  device  interlacing  is  greatly  simplified  in  that 
Pl-to-device  communications  can  be*  performed  via  a simple,  conventional  word-parallel  digital 
interface  amenable  to  rigid  standardization.  I lus  simple  interfacing  technique  is  allowed  clue  to 
the  localization  of  the  external  device  and  its  "interface  PI-..”  Since  the  PI  may  be  assigned 
system  functional  processing  tasks  in  addition  to  those  of  a mere  “I  ()  device  handler/ 
preprocessor."  the  bus  interface  hardware  used  by  the  PI:  in  its  system  processing  role  can  also 
he  used  to  distribute  I O device  data  throughout  the  system,  if  required  by  other  processing 
functions  i PI  si.  Unis,  a common  hardware  resource  is  used,  or  "shared."  by  both  processing  and 
external  il  ()l  device  entities. 

In  addition  to  the  above  advantages,  the  chosen  approach  also  affords  a greater  degree  of 
control  and  pertorniance  m the  distributed  function  processing  environment  since  the  access  to 
jnd.  hence,  operation  of  ejeh  external  device  is  controlled  by  an  "intelligent"  member  of  the 
processing  system.  The  same  consideration  of  overlapped  tis«.  o|  resources  is  applicable  here  as 
previously  mentioned,  only  with  respect  to  usage  ot  the  data-processing  portion  ot  the  Ph. 
Again,  the  external  device  interface  hardware  burden  is  lessened  and.  moreover,  the  integration 
of  "smart  sensors"  into  the  inlormation  system  is  readily  accommodated.  In  summary,  the 
multi-level  communication  struct ua*  design  offers  the  potentially  lowesKost  approach  that  is 
compatible  with  DP  M system  operational  objectives  without  impairing  system  functionality  and 
reliability. 
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SECTION  III 

INFORMATION  TRANSFER  BUSES 


A.  OVERVIEW 

All  DP  M intra-system  communications  are  accomplished  via  a simple  set  of  “party-line” 
data  buses,  the  number  of  which  depends  upon  system  requirements  of  functionality  and 
reliability . This  inter-Pl-  busing  facility  is  structured  to  facilitate  transmission  of  common, 
interprocess  ("global”)  data  elements  and  system  control  information  (e.g..  aircraft  state  vector 
and  system  executive  control  information)  to  all  Pl-.s.  Also,  the  busing  structure  supports  the 
transmission  of  uniquely  "localized”  data  items  between  PLs  associated  with  the  performance  of 
a single  function  or  process,  or  between  closely  related  processes,  referred  to  hereafter  as 
"affinity  groups.”  The  information  transter  facility  is.  then,  a hybrid  structure  consisting  of  a 
global  communications  bus  and  a variable  number  of  dedicated  “local”  communications  bus 
links.  The  number  of  individual  local  links  depends  upon  individual  system-processing 
requirements.  These  buses  are  incorporated  in  an  inter-PE  communication  facility  structural 
design  which  resulted  from  the  following  inter-Pi-  communication  system  design-intent 
philosophy 

A global  “party-line”  facility  must  be  available  to  all  Pi  s for  transfer  of  system 
control  and  interfunctional  process  data.  A global  "broadcast”  capability  is 
desirable  to  accommodate  multiple-destination  transmissions  with  minimum 
bus  bandwidth  usage. 

A separate  "local”  communication  facility  tor  intrafunct tonal  data  transfers  is 
desirable  to' 

Increase  system-expansion  capability  by  alleviating  possibility  of  global  bus 
traffic  overflow 

Increase  throughput  expandability  of  the  total  system  by  localizing 
high-data-rate  transfers  associated  with  the  performance  of  an  individual 
process.  These  transfers  can  be  associated  with  intra-functional  process 
data-passmg  or  distribution  of  external  device  (I  O)  data  among  a group 
of  common  10  data  subscribers  (I  O data  is  typically  related  to  a 
unique,  specific  avionic  function  I. 

Otter  improved  system  response  time  associated  with  time-critical  data 
transfers  for  unique  processing  requirements  by  transmitting  critical  data 
via  high-priority,  low-traffic  localized  bus. 

Otter  backup  capability  for  global  bus  connection. 

Since  processing  power  can  be  scarce  in  a microprocessor-implemented  system, 
bus-message-transter  activity  should  not  signiln.ar.tly  affect  the  operation  of 
Pi  s not  involved  in  the  exchange  and  should  require  minimum  program 
intervention  control  in  affected  Plis.  i.e..  the  busing  facility  element! sf  should 
augment  the  processor  (software)  in  the  handling  of  mtcr-PI'  data  transfers. 

Busing  facilities  should  allow  maximum  data  transfer  efficiency  for  varying  system 
communication  requirements. 
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Buses  should  support  physical  distribution:  i.e..  the  busing  facility  should  permit  and 
facilitate  inter-PI  com  mu  meal  ions  over  diverse  path  lengths  (up  to  300  feet! 

Biisine  system  design  should  allow  low-risk  technology 'implementation  within  LSI 
constraints. 

I he  Busing  system  should  facilitate  modular  system  growth,  or  reconfiguration, 
while  incorporating  a set  of  homogeneous  communications  elements  (devices! 
o!  as  few  types  as  possible. 

B.  SYSTEM  REQUIREMENTS  AND  CONSIDERATIONS 

The  DP  M communications  lacility  structural  design  was  developed  around  the  generalized 
design  goals  discussed  previously  Details  of  the  communications  facility  elements  design(sl  were 
driven  by  the  following  unique  requirements  generated  from  a top-down  analysis  of  a 
representative  DP  \1  avionic  system  operational  environment. 

1.  Distributed  Systems  Environment 

One  of  the  pristine  system-level  criteria  driving  the  DP  M Processing  Element  conceptual 
design  is  the  requirement  that  the  PI  must  be  capable  of  operating  in  a totally  distributed 
system  environment  to  be  applicable  in  a wide  variety  of  distributed  system  architectures.  With 
respect  to  communication  facility  characteristics  and  capabilities,  this  requirement  precludes  the 
assumptive  reliance  on  a purely  centralized  or  system-synchronous  data  transfer  approach. 
Consequently . the  PI  should  be  able  to  operate  in  a totally  asynchronous  information  transfer 
environment  where  data  transfer  events  are  not  strictly  time-ordered.  This  design  approach  is  in 
partial  contrast  to  present  integrated  avionics  system  design  efforts,  but  it  affords  a more  truly 
generalized,  versatile  approach  which  is  compatible  with  a wide  range  of  potential  system 
applications.  Tins  mter-PI  communications  lacility  approach  is  vital  in  the  realization  of  a truly 
versatile,  system  building-block  PI  design. 

2.  \ircratf  Equipment  Compatibility 

Fo  ease  the  integration  eltorl  needed  to  deploy  DP  M in  existing  aircraft  systems  and  thus 
enhance  the  overall  cost  effectiveness  of  the  DP  M approach,  it  was  considered  desirable  to 
attempt  compatibility  between  the  communications  facility  design  and  existing  aircraft 
information  distribution  equipment.  Standardization  approaches  to  aircraft  internal  data 
distribution  equipment  are  underway  within  the  military.  It  is  believed  that  the>**  programs  will 
result  in  a forthcoming  generation  ol  digital  avionics  devices  with  standardized  interfaces  to  a 
data  busing  lacility.  I he  foremost  representative  of  current  programs  is  MIL-STD-1 553. 

For  the  purpose  of  future  aircraft  system  compatibility,  it  was  decided  to  provide  I)P/M 
compatibility  with  the  design  intent  expressed  for  avionic  system  configurations  in 
MIL-SI l>l  553.  i.e..  given  the  visibility  atlorded  by  this  standard  into  the  probable  characteristics 
ol  future  aircraft  system  equipment,  the  DP  M communication  interlace  facilities  design  should 
reflect  these  characteristics.  In  particular,  the  characteristics  under  concern  are  those  of  digital 
aircraft  equipment  interfaces  and  physical  uata  distribution  facilities  (e.g..  data  bus 
characteristics!.  Therefore,  physical  and  electrical  compatibility  with  equipments  derived  from 
MII.-STD-1 553  is  emphasized,  whereas  exact  functional  adherence  to  the  standard  is  of 
second-order  significance 
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.V  System  Performance  Requirements 


Ihe  DP  M 1*1  must  not  only  meet  the  tunetion.il  lequiicinents  imposed  In  its  distriluited 
svstem  environment.  Init  must  also  he  compatible  with  both  the  jjener.il  and  the  unique 
perlormuncc  requirements  o!  its  mtemled  applications  Accordingly.  the  following  system 
communications  requirements  were  identified  and  analyzed  to  define  the  peiformance 
characteristics  required  of  the  information  transfer  facility  design. 

a Bus  Traffic  hei/uirciuents 

It  lias  been  ascertained  in  several  studies  that  the  actual  communications  bandwidth 
requirements  o:  contemporary  avionic  systems  can  h-  easily  met  win.  I Mbps  serial  data  link.  An 
anab.sjs  of  file  lata  traiisler  requirements  of  each  processing  task  envisioned  for  the  DP/M 
baseline  system  was  performed  using  Ihe  data  generated  front  previous  PPM  and  integrated 
avionic  mission  processing  requirements  definition  studies  (see  bibliography  l.  Because  it  was 
decided  to  mainta.n  electrical  interface  compatibility  with  conventional  airuaft  data  bus 
standards,  a I Mbps  serial  bus  data  rate  was  assumed  and  all  tralfic  estimates  were  thus  measured 
in  units  of  kilobits  per  second  (Kbps' 

The  bus  traffic  analysis  reflects  the  results  of  applying  the  busing  system  design  to  the 
data  transfer  requirements  of  the  worst-case  mission-processing  segment.  The  actual  amount  of 
bus  traffic  encountered  by  the  busing  system  at  any  given  period  in  the  life  of  an  aircraft 
mission  is  dynamic  (varies  within  predetermined  limits!,  depending  on  the  processing 
requirements  of  different  mission  segments.  The  segment  analyzed  i Postulated  as  the  worst-case 
processing  segment,  both  in  terms  of  processing  throughput  and  bus  communication  traffic. 
Detailed  information  concerning  busing  protocol  characteristics  and  additional  overhead  imposed 
by  those  characteristics  is  discussed  in  a subsequent  section,  tor  purposes  relevant  here,  bus 
traffic  is  composed  of  transmission  of  unique  serial  data  bit  strings  known  as  messages.  Hach 
message  contains  the  basic  generic  information  elements  listed  in  I able  2 

These  data  distribution  characteristics  wcie  used  in  determing  the  bus  traffic 
decomposition  and  subsequent  overhead  contribution  analysis  I ach  element  ot  information 
transferred  via  a bus  m order  to  move  data  from  PI  to  PI  was  segregated  to  allow  a 
determination  ot  the  relative  amount  of  bus  bandwidth  consumed  by  that  individual 
element  function  This  data  was  desired  to  allow  (via  busing  facility  design  modification! 
elimination  ot  overbearing  overhead  elements,  il  required. 

The  total  message  flow  required  between  interacting  processing  tasks  was  segregated  into 
global  and  local  groupings  The  overall  system  data  distribution  traffic  requirements  ot  the 
baseline  system  are  summarized  in  Table  .v  The  global  Inis  t rat t is  is  comprised  of  both 
mtertunctional  l inter-affinity  group!  data  and  (ilobal  I \ecutivc  ( omm.uid  Control  information. 
The  bus  traffic  required  for  the  executive  functions  was  estimated  from  assumed 
function  suhtunction  scheduling  command  requuements  in  keeping  with  the  (ilobal  I .xecutive 
Control  strategy  described  in  Section  VIII  of  this  report,  local  bus  traffic  is  a Junction  of  the 
physical  interconnections  ot  sets  of  PI  s within  affinity  groups,  in  the  local  bus  troll ic  analysis,  it 
was  assum’  d that  Pi  s and  their  associated  processing  tasks  are  grouped  into  common  functional 
groupings  (e.g..  navigation,  weapon  delivery,  etc.!.  In  addition,  to  arrive  at  a worst-case  bus 
traffic  prediction,  each  PH  within  an  affinity  group  t tutu  timid  grouping*  was  assumed  to  contain 
a single  processing  task  involved  in  that  fuiKtioii.  In  .Mtinhiy.  more  than  one  task  will  be 


I ABLE  INFORMATION  TRANSFER  BUS  TRAFFIC  DECOMPOSITION 


Traffic  Element 

Global  Traffic 
(Kbps/ Percent  of  Total) 

Local  Traffic 
(Khps/Percen(  of  To(al) 

Total  .ombined  Traffic 
(Kbp- 'Percent  of  Total) 

Raw  data 

55.6  49  0 

234  1 6X  9 

267  7 65  6 

Data  packing 

i.s  s 20  i 

6\S  |9  3 

•’U.d  |9  4 

Message  bcailcr 

i : 3 r >» 

I4n  43 

26  u 6 0 

Message  s\  iu 

: ti : o 

2 : » 7 

4.2  1 0 

Data  patitv 

» (>  s s 

t‘»  5 5.7 

25  1 5 7 

Inter  message 

S S 4 ,N 

.'"’ll 

7.0  1.7 

cap  time 
Total  ttafiu 

6X  (>  Kbps 

.'.il,.(>  Kbps 

40S  2 Kbps 

) ttkieiKV 

49.0  peicent 

(iK*>  peicent 

65  6 peicent 

TABLE  i.  DATA  DISTRIBUTION  TRAFFIC  (BANDWIDTH)  REQUIREMENTS 


Lomm  unication 

Traffic 

Data  T..pe 

Facility 

(kilobit  s/second) 

Interfur. uonal 

Global  bus 

69.5 

System  control  (executive) 

Globa!  bus 

105.K 

Intiatununmal 

Local  Hus 

Maximum  function 

I7I.S 

Total  System 

345.7 

1 vicinal  Device 

Input  output 

Mavmiut.  PI 

522  2 

Total  system 

''62.4 

allocated  per  PI'  since  the  envisioned  processing  power  (throughput)  of  a PF  is  substantially 
greater  than  that  required  for  the  performance  of  most  tasks  identified.  Thus,  the  results  shown 
for  the  local  bus  traffic  represent  a very  conservative  worst-ease  requirement. 

It  is  recognized.:  however,  that  actual  traffic  encountered  in  a particular  system 
configuration,  may  require  addition  of  some  I'O  data  into  the  busing  system  for  reasons  of 
physical  distribution,  thus  causing  the  bus  traffic  to  increase  somewhat  at  either  or  both  global 
and  local  levels.  Assuming  a I Mbps  data  rate  capability  for  the  information  transfer  buses,  this 
concern  is  greatly  relieved  owing  to  the  amount  of  bus  bandwidth  margin  remaining  and  the  fact 
that  most  distributed  I/O  data  will  be  confined  to  affinity  groups  (local  buses  only).  The 
bandwidth  margin  experienced  indicates  that  most  Pi  s of  the  assumed  processing  caliber  used  in 
an  avionics  processing  suite  will  tend  to  be  ome  throughput  or  storage  bound  before  they 


approach  becoming  "l  O-bouiui.”  Tins  apparent  inefficient  use  of  the  PE's  functional  resources  is 
actual!)  a desirable  situation  with  respect  to  the  DP/M  system  in  that  it  indicates  flexibility  for 
future  system  growth/reconfiguration  in  the  communication  facility  of  the  system  building  block, 
the  PI  . The  communication  facility  is  the  one  functional  resource  which  typically  restrains 
“expansion"  as  system  growth  is  introduced:  i.e..  as  functional  capabilities  are  added  to  a DP/M 
system,  the  added  processing  load  can  usually  be  countered  by  the  addition  of  PEs  within  the 
function,  but  the  added  communications  traffic  introduced  by  this  addition  must  be  absorbed  by 
the  existing  busing  facility  This  situation  exists  because  the  bandwidth  capabilities  of  the 
communication  system  are  fixed  at  the  time  of  design  and  are  not  incrementally  expandable  as  is 
typical!)  the  case  with  processii  g and  memory  resources.  Therefore,  the  bus  traffic  analysis 
indicates  that  the  proposed  communication  facility  will  offer  a comfortable  degree  of  system 
expansion  flexibility  unless  data  transfer  overhead,  caused  by  the  facilities  protocol  requirements, 
significantly  increases  total  bus  traffic. 

b.  Real-Time  Response  Requirements 

In  addition  to  the  data  throughput  requirement  on  the  busing  facility  by  inter*PE 
communications,  the  asynchronous  nature  of  the  distributed  system  requires  that  special 
consideration  be  given  to  the  response  time  of  the  communications  interface.  The  response  time 
addressed  here  is  the  time  allowed  to  process  a received  message  in  a given  PE  and  to  setup  the 
bus-interface  before  reception  of  the  subsequently  received  transmission.  This  control  timing 
relatic  nship  is  especially  rigorous  in  the  totally  asynchronous  distributed  environment  since  the 
time  interval  between  messages  transmitted  to.  or  received  by.  a given  PE  is  not  easily 
controllable  within  the  system  without  sacrificing  total  system  performance  and/or  interface 
hardware  complexity.  Therefore,  the  interlace  element  and  the  communication  protocol  design 
were  formulated,  with  this  consideration  being  given  priority.  The  actual  response  time  constraint 
was  analyzed  in  the  following  manner. 

Dus  message  response  time  is  primarily  governed  by  the  amoun*  of  time  spent  in 
processing  input  messages  as  they  are  received  in  real  time.  The  process  of  input-message 
handling  includes  the  actions  required  on  the  part  of  the  Local  Executive  software  ( LEX)  to 
properly  recognize,  validate,  correlate,  and  disseminate  the  incoming  messages  for  application 
tasks  from  both  global  and  local  bus  interfaces.  A worst-case  analysis  of  response  reaction  timing 
to  input  messages  was  performed,  assuming  the  asynchronous  busing  facility  operational 
characteristics. 


Vectoring  of  the  received  message  data  sets  to  user-accessible  buffer  areas  was  recognized 
as  an  area  of  design  concern.  Timing  considerations  associated  with  message  vectoring  require 
that  the  bus  interface  be  set-up  to  re-vector  each  successive  message  by  establishing  a new  buffer 
starting  address  and  buffer  length  to  the  bus  interface  input  channel(s).  This  set-up  process  must 
occur  before  the  receipt  of  the  next  message  or  the  required  data  will  be  lost  because  of  the 
“over-writing"  effect  of  the  following  message  input.  To  determine  the  severity  of  such  response 
timing  constraints,  a worst-case  message  transfer  situation  was  determined  and  analyzed.  The 
situation  identified  is  shown  in  Figure  7.  It  occurs  when  the  PE  receives  both  global  and  local 
input  message  completions  simultaneously.  Following  receipt  of  these  messages,  if  the  next, 
immediate  local  message  is  a message  destined  to  the  same  PE  (i.e..  back-to-back  message 
receipt!,  the  minimum  time  allowed  before  the  input  channel  begins  the  next  message  input 
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land.  thus.  both  requires  the  new  butter  set-up  information  and  destroys  the  last  received 
message  identilicationt  is  only  42  microseconds.  This  response  tune  is  well  beyond  the  interrupt 
response  tune  and  processing  capabilities  of  a micro-class  processor.  It  was  determined  that  the 
Bus  Interface  Tint  (Blit  design  should  aid  and  facilitate  the  solution  of  this  response-time 
problem. 

<*.  Ph.  Performance  Aiding 

As  mentioned  in  the  overall  objectives  of  the  mtei-PF  communications  facility  design,  this 
facility  should  not  place  any  undue  burden  on  processing  requirements  for  the  PI:  and  should 
cltectively  augment  the  PI  in  its  message  processing  duties  by  alleviating  processor  intervention 
m message  input  output  activities  as  much  as  possible  without  severely  complicating  the  bus 
interlace  hardware  requirements.  Phis  design  goal  is  very  important  in  allowing  maximum  use  of 
the  PI  m all  information  processing  tasks  due  to  a reduction  in  “overhead"  activities., 

d.  stem  Design  Simplicity 

The  information  transfer  facility  should  be  dt  igned  to  use  simplified,  low-risk,  low -cost 
hardware  Special  attention  should  be  given  to  design  impact  on  modular  LSI  implementation 
applicability.  Additionally . the  communication  facility  structire  should  allow  use  of 
homogeneous  elements  of  as  tew  unique  part  types  as  practical  if  the  goals  of  a modular 
butiding-hiock  approach  to  versatile  system  design  and  low  life-cycle  cost  are  to  be  eventually 
realized. 

4.  System-Level  Fault-Tolerance  Implications 

Sine  - the  global  busing  facility  is  the  only  "central"  resource  of  the  DP  M system,  it 
should  be  fault-tolerant  within  itself  and  should  be  instrumental  in  aiding  fault  recovery  in  all 
other  system  elements.  In  keeping  with  the  simplified  system  hardware  approach,  fault  tolerance 
in  the  communication  facility  is  effected  by  orderly,  system-software  controlled  recovery 
procedures  in  response  to  detected  errors  faults  within  the  communications  facility..  Thus,  it  is 
the  responsibility  ol  the  bus  interface  hardware  to  provide  the  necessary  failure  detection 
mechanisms  required  to  accommodate  this  approach  to  fault  tolerance  at  the  system  level. 

C.  BUSING  FACILITY  DESIGN  CHARACTERISTICS  AND 

TRADEOFF  CONSIDERATIONS 

The  present  functional  design  ol  the  intcr-PI  communication  facility  is  the  result  of  a 
series  ot  design  alternative  and  tradeoff  investigations  winch  progressed  gradually  during  the 
study.  Tradeofls  were  judged  n accordance  with  the  system-level  communications  facility  design 
criteria  set  forth  in  previous  discussions.  The  following  discussions  are  related  to  the  delineation 
ot  various  basic  busing  system  functional  design  parameters  and  the  design  tradeoffs. 

I.  Data  Link  Type 

All  intcr-PI  communications  arc  accomplished  via  a set  of  bit-serial,  time-division 
multiplexed  (TDM),  i Mbps  data-rale.  twisted-pair  cable  (single  signal  line!  bus  data  links.  The 
recommended  bus  common  and  electrical  interlace  characteristics  of  these*  serial  ' •‘'■>rmation 


transfer  buses  are  identical  to  those  defined  and  specified  by  recent  standards  for  aircraft 
information  distribution  systems  (e.g.,  MIL-STD-1 553).  The  advantages  and  applicability  of  this 
approach  to  information  distribution  in  the  aircraft  environment  are  documented  in 
contemporary  studies  and  need  not  be  repeated  here.  In  addition  to  the  functional  and  physical 
advantage",  ottered  by  this  data  distribution  approach  to  the  DP/M  system,  adoption  of  this 
standardized  bus  common  hardware  concept  for  DP/M  would  greatly  facilitate  integration  of  a 
DP/M  system  into  future  avionics  systems  incorporating  standardized  bus  equipments. 

2.  Bus  Language 

Due  to  considerations  of  physical  distribution  and  length  disparities  allowed  in  PE-to-PE 
bus  lengths  (up  to  300  feet)  and  reliability  in  the  aircraft  environment,  data  should  be  conveyed 
along  the  bus  using  an  asynchronous  transmission  technique.  Asynchronous  transmission  means 
transmitting  information  in  a manner  which  combines  clocking,  or  bit-framing,  information  along 
with  the  actual  binary  data  in  a single  signal. 

To  meet  the  above  requirement,  biphase  level  (Manchester  II)  binary  data  encoding  is  to 
be  used  for  bus  data  representation.  The  encoding  technique  is  popular  in  aircraft  data  bus 
standards  < i.e. . MIL-STD-1  553):  thus,  it  is  a proven  technique,  ensuring  DP/M  communications 
facility  compatibility  with  available  (future)  aircraft  data  bus  hardware  (Manchester  II 
encode/decode  equipment).  The  DP/M  busing  facility  should  allow  use  of  the  data  and 
synchronization  signal  representation  specified  in  M1L-STD-I553  and  shown  in  Figure  8. 

3.  Bus  Control 

Since  the  physical  inter-PE  communications  media  are  shared  by  multiple  PEs,  some 
mechanism  must  be  included  in  the  communication  facility  design  to  provide  proper  allocation 
control  of  the  common  bus  facility  among  all  users  of  the  bus.  Bus  control  means  how  the 
individual  PE  allowed  to  transmit  data  on  a given  bus  at  a given  time  is  determined.  Basically, 
there  are  two  general  approaches  to  achieving  orderly  bus  control:  “Centralized" „ and 
“Decentralized.”  The  main  difference  between  the  two  techniques  is  the  physical  location  of  the 
bus  access  resolving  logic. 


In  general,  a centralized  control  scheme  requires  that  a single,  “intelligent”  control  entity 
included  in  the  system  is  responsible  for  all  control  activity.  In  a DP/M  system,  however,  this 
philosophy  has  several  disadvantages  compared  with  a distributed,  or  decentralized  approach. 
Since  the  DP/M  system  is  composed  of  a set  of  homogeneous  PEs,  the  hardware  required  to 
achieve  centralized  control  must  be  used  in  each  PE.  Depending  on  the  type  of  bus  assignment 
technique  used,  total  system  hardware  requirements  may  increase,  which  is  equivalent  to 
providing  the  hardware  for  decentralized  control.  Since  the  DP/M  system  is  intended  to 
accommodate  multiple  TDM  buses  (global  plus  local),  a PE  for  each  bus  is  needed  to  provide  the 
control  function.  Depending  on  the  allocation  scheme  used,  this  PE  role  of  “Bus  Executive”  may 
use  a significant  portion  of  the  processing  capabilities  of  t c PEs  responsible  for  bus  control. 

The  centralized  bus  control  hardware  technique  represents  a critical,  single-point  system 
failure  source  because  a fault  in  the  control  hardware  could  disable  the  entire  system.  Recovery 
from  centralized  controller  failure  requires  complex  redundancy  or  back-up  controller  scheme. 
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Tlie  reliability  of  properly  implemented  decentralized  control  is  usually  superior  because  most 
bus-control-related  failures  will  only  disconnect  the  associated  PE  from  the  bus.  Depending  on 
the  allocation  scheme  used,  the  centralized  control  approach  is  usually  less  flexible  for  system 
growth  or  reconfiguration  than  is  decentralized  control. 

Using  a single  bus  line  for  transferring  both  allocation  commands  and  data,  a centralized 
control  approach  reduces  effective  bus  bandwidth  because  of  the  bus  overhead  introduced  by  the 
presence  of  command  information  sent  over  the  bus  between  each  transfer  of  data  (message 
transfer).  Decentralized  control  results  in  faster  allocation  of  the  bus  to  users  and  offers  more 
efficient  use  of  available  bus  bandwidth.  However,  centralized  control  is  better  with  respect  to 
dynamic  bus-user  priority  resolution  and/or  strict  ordering  or  timing  of  the  transfer  of  data 
elements  (messages)  with  respect  to  each  other.  This  advantage,  though,  is  not  of  great 
significance  in  the  avionics  environment  since  the  bus  requirements  of  each  PE  (processing  tasic) 
can  be  reasonably  forecast  at  system  design:  i.e.,  the  communication  requirements  are  static,  not 
dynamic  in  nature.  Furthermore,  the  timing  relationships  between  individual  data  transfers  from 
(to)  different  processing  tasks  are  typically  not  critical  within  the  realm  of  responsiveness 
Chough  statistical)  offered  by  a decentralized  control  technique  with  a 1 Mbps  data  rate  bus. 
Exceptions  to  this  general  rule  can  be  handled  with  proper  bus  assignment  technique,  as 
discussed  subsequently. 

Another  potential  advantage  of  centralized  control  is  the  hardware  simplicity  it  affords 
when  uscu  with  “dumb"  terminals  which  do  not  possess  the  “intelligence"  to  determine  their 
own  bus  access  requirements.  Again,  however,  this  advantage  is  not  applicable  in  a DP/M  system 
where  all  bus  terminals  are  “smart"  terminals  (PEs). 

The  above  considerations  of  centralized  and  decentralized  bus  control  attributes  favor  a 
decentralized  approach  in  a DP/M  system.  A decentralized  approach  is  further  justified  by 
consideration  of  the  previously  outlined  DP'M  system-level  design  objective  which  requires  that 
the  homogenous  building  block  Processing  Element  be  compatible  with  those  system  operational 
constraints  present  in  a totjlly  distributed  system  application  environment.  Centralized  control  in 
the  context  of  a central  command  source  for  establishing  and  timing  all  inter-PE  communications 
activity  is  representative  of  conventional  “federated"  system  approaches.  The  federated  system 
configuration  is  a special,  but  not  general,  class  of  distributed  system  architecture:  and  confining 
the  communication  facility  to  this  class  of  environment  was  feared  to  preclude  application  of 
other  possible  system  configurations,  'therefore,  the  decentralized  bus  control  approach  was 
adopted  for  DP'M  in  an  effort  to  eliminate  any  busing  facility  dependencies  on  particular 
distributed  system  applications  or  configurations. 

4.  Bus  Assignment 

Bus  assignment  refers  to  the  method  by  which  each  bus  user  (PE)  is  allocated  access  to.  or 
control  of.  the  shared  bus  facility.  Since  the  bus  control  technique  favored  was  the  decentralized 
approach,  several  basic  types  of  bus  allocation  or  assignment  were  considered:  however, 
system-level  desirability  of  using  a single  signal  line  (bus)  for  all  data,  timing,  and  control 
information  reduces  the  set  of  candidate  techniques,  with  the  primary  candidate  being  static 
scheduling  according  to  “position"  in  a cyclic  control  sequence.  A static  scheduled  bus 
assign  merit  approach  allocates  the  bus  to  individual  users  based  on  a repetitive,  fixed-sequence 
algorithm.  This  technique  is  commonly  used  in  TDM  telemetry  systems  where  the  bus  allocation 
requirements  of  each  individual  data  source  are  predictable,  based  on  a priori  knowledge  of 


system  operational  characteristics.  Each  bus  user,  or  data  source,  is  assigned  a unique  “slot"  in 
the  total  bus  allocation  piocedure  cycle. 

The  algorithm  chosen  for  scheduling  the  bus  facilities  is  a modified  “round-robin"  slotting 
technique  which  provides  for  simple  advancing  of  the  "bus  control  slot"  from  PE  to  PE.  in  a 
predetermined  order,  among  the  total  set  of  PEs  attached  to  the  bus.  This  round-robin  technique 
affords  a modularity  attribute  typical  of  “daisy-cha.'n"  techniques  without  the  reliability 
problems  of  daisy-chain  control  (unctions.  This  algorithm  incurs  a relatively  unpredictable  system 
responsiveness  to  user  requests:  i.e.,  the  latency  time  between  the  generation  of  data  la  message) 
to  be  transferred  on  a bus  and  the  receiving  of  bus  access  by  the  associated  PE  is  indeterminate. 
This  latency  time  is  a function  of  the  number  of  bus  users  and  messages  transferred  before 
control  is  procured.  As  a consequence  of  the  avionics  system  and  the  DP/M  system  design 
philosophy,  the  avionics  application  can  tolerate  a statistical  distribution  of  bus  access  latency 
without  suffering  degradation  in  performance.  To  accommodate  unique  or  critical  scheduling 
requirements  of  high-priority  data  transfers,  it  was  determined  that  the  bus  assignment  algorithm 
should  allow  some  level  of  super-commutation  of  bus  allocation  time  slots.  The  super- 
commutating approach  allows  assignment  of  multiple  bus  access  slots,  cr  usage  opportunities,  to 
particular  bus  users  during  each  cycle  through  all  users.  The  users  can  be  prioriti/ed  to  assure 
them  of  a particular  percentage  of  available  bus  bandwidth  and/or  minimi/cd  access  latency. 

To  advance  or  propagate  the  bus  assignment  sequence  around  the  total  set  of  bus  users,  a 
method  was  chosen  for  delimiting  or  framing  individual  bus  transmissions  (per  allocation  slot). 
Each  bus  transmission,  referred  to  as  a message,  is  terminated  by  the  transmitting  PE.  Message 
termination  is  denoted  by  placing  an  end-ot-message.  or  message-sync  signal  on  the  bus 
immediately  following  the  last  data  bit  in  the  message.  If  a PE  cannot  transmit  data  when  it 
receives  bus  access,  it  merely  “passes"  control  to  the  next  subsequent  bus-controlling  PE  by 
transmitting  only  the  message-sync  signal. 

While  a PE  has  control  of  a bus.  it  may  transmit  a variable-length  message  as  desired- 
Considerations  of  response-time  requirements  for  system  control  information  transmission  led  to 
the  decision  to  limit  the  maximum  length  of  global  bus  messages  to  eight  data  words.  This 
arbitrary  choice  was  made  as  an  attempt  at  a reasonable  compromise  between  global  message 
lengths  encountered  in  the  system  processing  requirements  analysis  and  tentative  estimates  of 
(ilobal  Executive  system-level  response  time  n.e..  bus  access  latency)  requirements. 

5.  Bus  Communication  Method 

(iiven  the  above  decisions  to  incorporate  a decentralized  control  technique  with  static- 
scheduling  of  bus  allocation  to  multiple  PE  bus  users,  the  next  design  characteristic  addressed 
was  the  method  by  which  a PE  transmits  data  to  other  PEs  after  it  has  gained  control  of  the 
bus.  An  asynchronous  scheme  of  data  transmission  between  transmitter  and  received s I was 
already  recognized  as  a firm  requirement  owing  to  consideration  of  physical  distribution,  data 
integrity,  and  overall  reliability  of  the  communication  system.  (The  term  "asynchronous"  as  used 
here  means  that  no  common  data  timing  or  clock  source  is  required  between  transmitter  and 
receiver.) 

Asynchronous  communication  alternatives  basically  can  be  categorized  into  responsive  and 
nonresponsive  methods.  Responsive  communication  requires  a response  from  the  data 
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destination,  or  receiver,  which  affirms  the  correct  receipt  of  the  transmission  This  respond-back 
characteristic,  however,  increases  bus  traffic  overhead  and  thus  reduces  effective  bus  bandwidth 
and  efficiency.  Principal  advantages  of  the  responsive  technique  are: 

• Accommodation  of  communication  between  nonhomogeneous  devices. 

• Rapid  notification  to  the  data  transmitter  of  correct  or  incorrect  receipt  of  data  at 

the  receiver. 

The  former  advantage  obviously  does  not  apply  in  a DP'M  system  because  ail  bus  users  art- 
homogeneous  PEs.  The  latter  advantage  is  valid  but  of  uncertain  value  in  the  DP/M  system 
application.  Of  primary  importance,  in  conjunction  with  the  receipt  of  incorrect  data  or  a faulty 
transmission  at  a receiving  PF.  are  detection  of  and  notification  of  the  fault  to  the  data  user 
(processing  task!.  If  transmitted  data  errors  are  detected  in  the  message  transmission,  the  user 
process  has  the  basic  options  of: 

Waiting  for  the  next  subsequent  transmission  of  the  data 

Ignoring  the  data  and  using  old  or  extrapolated  data  values  from  previous 
transmissions  of  the  data  set  (applicable  to  iterative  or  cyclic  processes) 

if  previous  data  cannot  be  used,  a request  can  be  sent  to  the  data  source  for 
retransmission  of  the  data  set  in  error  via  normal  bus  access  procedure:  i.e..  a 
responsive  communication  sequence  can  be  effected  with  a nonresponsive 
facility. 

If  process  or  data  criticality  is  such  that  none  of  the  above  basic  options  is  satisfactory,  the 
critical  data  (messages)  may  be  multiply  transmitted,  with  the  transmitting  PF  assigned  a high 
priority  in  the  bus  control  sequence  < super-commutated  *.  Alternatively,  critical  data  can  be 
transmitted  with  error-correcting  code  techniques  to  allow  reconstruction  of  the  correct  data  by 
the  data  user.  These  procedures  are  applicable  to  offering  a relatively  high  degree  of 
responsiveness  to  message  data  correction  requirements  for  data  transmission  errors  only:  message 
errors  (data  or  message  structure/protocol)  caused  by  transmitter/receiver  faults  are  typically 
nonrecoverable  by  a simple  retransmit  procedure.  Thus,  the  degree  of  responsiveness  in  such 
cases  is  not  critical  since  hardware  fault  recovery  must  be  accomplished  by  either  system 
software  or  hardware  elements. 

The  preceding  considerations  resulted  in  the  choice  of  a nonresponsive  bus  communication 
technique.  The  only  advantageous  feature  of  responsive  communication,  the  facilitation  of 
message  retransmission  due  to  detected  message  data  errors,  was  not  considered  to  be  of  special 
value  ir  »he  DP/M  system,  especially  when  compared  to  the  advantages  of  bus  efficiency  and 
hardware  simplicity  afforded  by  the  nonresponsive  technique. 

^he  nonresponsive  communication  method  chosen  is  an  output  demand  driven  metluKl 
whereby  each  bus  user  transmits  its  exclusive  data  sets  ( messages)  under  its  own  cognizance  after 
acquiring  bus  access.  A possible  alternative  to  this  approach  was  to  use  a command-response 
technique  whereby  data  can  be  either  sent  or  requested  by  a transmitting  PF.  Accomplishment 
ot  real-time  responsiveness  to  such  data  requests  in  a recipient  PF  would  require  either  complex 
hardware  in  the  bus  interface  unit  and/or  a decrease  in  effective  bus  bandwidth  caused  by  data 
response  latency. 
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Additionally,  a data  request  scheme  applied  in  the  block-oriented,  serial  data  transfer 
environment  of  the  inter-PE  communication  system  would  result  in  detrimental  effects  on  the 
applications  processing  throughput  of  the  system  because  of  applications-processing  latency,  or 
“hold-up."  due  to  relatively  lengthy  data  transfer  times  ti.e.,  the  wait  time  a data-block  user 
process  must  endure  during  the  data  retrieval  and  transmitting  process).  This  data  response 
latency  time  is  a function  of  message  overhead,  the  number  of  words  in  the  data  block,  and  the 
processing  overhead  time  associated  with  handling  the  data  in  the  recipient  PE  (interrupt  routine 
time).  This  time  was  estimated  to  be  on  the  order  of  50  ps  plus  1 7 gs  for  each  word  of  data 
transferred.  This  magnitude  of  data  response  latency  could  easily  increase  effective  applications 
processing  time  (hence,  decreasing  processing  throughput)  by  a significant  amount.  Additional 
processing  delay  is  possible  because  of  round-robin  bus  access  latency  with  respect  to  actual 
delivery  of  the  data  request  to  the  data  source  via  the  associated  information  transfer  bus. 
Possible  latency  contributions  by  this  factor  can  significantly  deteriorate  overall  processing 
throughput. 

Possible  alleviation  of  the  above  degrading  effects  on  applications  processing  throughput 
may  perhaps  be  accomplished  by  prudent  Local  Executive  (LEX)  software  design  (via 
“look-ahead”  procedures,  etc.).  However,  this  solution  was  judged  unsatisfactory  because  of  the 
added  LEX  complexity  it  would  require  and  the  inescapable  latency  uncertainties  associated  with 
bus  access  delays. 

Due  to  the  above  disadvantages  associated  with  the  performance  of  a “data  request"  mode 
of  data  transfer  in  the  DP/M  real-time  environment  and  since  it  was  decided  that  no  real 
functional  requirement  for  this  mode  of  operation  existed  in  the  DP/M  system  application,  it  was 
decided  that  the  system  would  operate  in  the  fashion  of  an  asynchronous,  loosely  ordered  data 
sampling  system  with  sample  timing  determined  within  each  individual  data  source  (PE).  This 
mode  of  operation  allows  autonomous  and  asynchronous  delivery  of  all  user  data  before  actual 
time  of  usage,  foregoing  the  requirement  of  synchronous  data  request/response  operations  and 
their  attendant  real-time  problems. 

Once  bus  access  is  gained  by  a PE,  it  then  transmits  a message.  The  length  of  time  that  the 
PE  is  permitted  to  retain  bus  usage  is  variable  and  is  equivalent  to  the  duration  of  the  single 
message  transmitted.  Each  message  is  a word  integral  transmission  of  a variable  number  «.f  data 
elements.  Global  messages  can  be  optionally  limited  to  a maximum  of  eight  data  words,  enforced 
by  system  software  protocol  and  monitored  by  bus  interface  hardware. 

When  a PE  is  not  transmitting  (i.e..  at  all  times  other  than  its  bus  access  slot),  it  remains 
in  an  active  “listening"  mode  as  a potential  receiver  of  each  transmitted  message. 

6.  Bus  Synchronization 

Data  between  a transmitter  and  all  receivers  can  be  synchronized  at  three  basic  levels: 
( l ) bit,  (2)  word,  and  (3)  message. 

Bit  synchronization  is  inherent  in  the  encoded  data  format  owing  to  the 
“embedded-clock”  property  of  Manchester  II  modulation. 


Word  synchronization  is  not  included  in  the  message  design  since  word  synchronization 
can  he  effectively  obtained  In  dividing  the  incoming  data  hits  modulo  the  fixed  data  word 
length.  In  addition,  no  valid  justification  for  including  a word  sync  on  the  basis  oi  data 
loss  recovery  during  transmission  errors  has  been  identified.  However,  actual  implementation  of 
the  B!l!  may  impose  word  sy  in  constraints  on  the  incoming  data  stream  within  a message,  such 
constraints,  though,  will  not  change  the  functional  design  ot  the  busing  facility. 

An  exception  to  this  word  sync  philosophy  exists  tor  the  special  case  of  the  message 
header  which  is  the  first  word  transmitted  in  a message.  Since  the  integrity  ot  this  data  word  is 
critical  to  proper  communication  facility  operation,  it  is  delimited  by  an  "end-of-header."  or 
"header  sync"  synchronization  signal  to  reliably  delimit  header  information.  This  technique 
greatly  improves  the  probability  of  detection  ot  header  data  errors  caused  by  bit  timing  errors. 

Message  synchronization  is  required  io  delimit  the  bus  allocation  time  slots.  Message  sync 
denotes  the  end  ot  a bus  access  slot  and  can  thus  be  used  by  the  distributed  bu  control  logic  to 
permit  bus  assignment  sequencing  at  the  proper  time.  The  message  sync  chosen  is  an  invalid 
Manchester  II  waveform  so  that  synchronization  information  can  be  discriminated  from  data 
patterns 

To  prevent  the  occurrence  of  message  overlap  caused  by  data  propagation  skew  between 
widely  separated  Pis  in  the  system,  inter-message  gap  timing  will  be  observed  and  enforced  by 
each  PI*.  flap  timing  is  a no-activity  time  inserted  between  the  message  sync  signal  and  the 
beginning  of  the  next  message  transmission.  To  ensure  circumvention  of  data  propagation  skew 
problems  in  the  1>P  M application  where  bus  length  diversity  between  Pi's  may  be  as  great  as 
300  to  500  feet,  a minimum  gap  time  ot  2-bit  times,  or  2 its  will  be  enforced,  bach  PI  bus 
interface  logic  will  wait  a minimum  ot  2 ps  alter  receiving  bus  control  tvia  detection  of  a 
message  sync  signal i before  beginning  data  transmission 

7.  Message  Structure 

I he  technique  used  to  establish  transmittei  lecciver  links  lor  each  message  was  a prime 
consideration  in  the  conceptual  design  of  the  inter-PI  busing  facility.  At  the  outset  of  the  busing 
facility  design,  it  was  recognized  tln.t  this  single  functional  design  characteristic  would  assert  a 
prominent  influence  on  the  overall  performance  of  the  busing  facility.  Design  of  a message 
routing  technique  must  consider  its  effects  on  the  following  system  parameters. 

Bus  haudwidth  efficiency 

Processing  throughput  overhead  incurred  it  address  recognition 
Message  handling  in  the  message  recipient 
System  configuration  and  application  flexibility 
f ault  tolerance 

Hardware  ii  plementation  requirements. 

Accordingly,  it  was  decided  that  the  message  routing,  or  addressing,  technique  adopted  should: 
htficienlly  support  me*  ag*  broadcasts  to  multiple  PI  s 
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Incur  minimum  interference  with  ongoing  PE  processing  during  the  address 
recognition  process 

Relieve  PE  processing  responsibilities  (software)  associated  with  the  handling  and 
control  of  message  receptions  within  the  PF,  program 

Accommodate  system  expansion  and  differing  applications  by  eliminating  physical 
dependencies  or  limitations  to  the  fullest  extent  practical 

Aid  system  reconfiguration  in  both  on-line  (in-flight)  and  off-line  (system  design) 
environments. 

The  routing  approach  chosen  is  a message-switched  approach  wherein  all  link-establishing 
information  is  present  in  the  actual  message  transmission.  Owing  U>  the  decentralized, 
static-scheduled  bus  assipiment  method  used  in  the  busing  facility  functional  design,  the  only 
routing  information  required  in  each  transmitted  message  is  addressing  information  which  can  be 
interrogated  by  all  other  (nontransmitting)  PEs  to  allow  individual  add  ?ss  recognition  and 
ensuing  message  reception. 

Conventional  message  routing/addressing  schemes  are  based  on  specification  of  the  physical 
address  of  the  desired  receiver.  This  approach,  however,  does  not  directly  support  message 
“broadcasting"  to  multiple  receivers  without  complicating  receiver  hardware  and  increasing  bus 
overhead.  With  this  approach,  broadcasting  must  be  effected  with  the  transmission  of  multiple 
headers  to  allow  specification  of  all  recipient  PE  physical  addresses.  Another  disadvantage  of  file 
physical  addressing  approach  exists  when  applied  in  a totally  distributed  system  environment.  As 
mentioned  previously  in  the  discussion  of  bus  control  design  tradeoff  considerations,  the 
communication  facility  system-level  design  constraints  precluded  the  assumption  that  a Central  or 
Global  Executive  entity  will  exist  in  all  DP/M  applications.  With  the  possible  absence  of  fiiis 
system  control  entity,  it  is  not  feasible  to  assume  that  the  various  distributed  PE  members  of  the 
system  may  each  contain  system  “resource  map”  information  if  dynamic  reconfiguration  is 
required  in  system  operation.  Without  this  distributed  knowledge,  re.  ".nment  of  messages  to 
physical  destinations  is  impossible,  and  therein  lies  another  weaknev  i physical  addressing  in 
DP/M  applications. 

With  the  undesirable  attributes  of  physical  addressing  identified,  “logical”  destination 
addressing  was  the  next  choice.  Logical  addressing  requires  assigning  a physically  independent 
identity,  or  logical  address,  to  each  bus  data  recipient.  To  achieve  physical  independence, 
identities  are  assigned  to  processes  contained  within  each  PE.  Thus,  tk  * Bus  interface  Unit  within 
ea<  h P'  must  be  capable  of  performing  an  associative  address  operation  on  each  incoming 
message  address  witli  the  set  ot  process  identities  (“soft"  names)  resident  within  the  PE.  The 
number  of  unique  associative  “names”  required  per  PE  interface  is  thus  dependent  on  the 
maximum  number  of  processes  allowable  within  a single  PE.  This  number  is  indeterminate  and 
must  be  arbitrarily  chosen  to  accommodate  a reasonable  number  of  processes  without  overly 
complicating  the  hardware  requirements  of  the  PE  Bus  Interface  Unit.  To  allow  message 
broadcasts,  a hierarchical  addressing  structure  is  available  with  the  logical  destination  naming 
approach  which  allows  a process  to  be  addressed  as  a unique,  single  entity  or  as  a member  of  a 
logical  or  functional  group  of  processes.  However,  this  technique  limits  process  membership  to  a 
single  group  and  does  not  allow  a true  universal,  flexible  broadcast  capability  without  further 
complicating  bus  interface  hardware. 
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During  the  design  process  associated  with  establishing  a desirable  message  routing 
technique,  it  wa«  determined  that  destination  information  alone  did  not  provide  enough 
information  to  allow  correlation  of  a message's  data  content  with  a particular  use  or  user;  i.e., 
multiple  data  sets  received  by  a given  PI£  or  a process  within  a PE  must  somehow  be 
differentiated  t message  data  demultiplexing  1.  Message  discrimination  requires  that  a message 
identifier  (Message  I.D.)  coexist  in  the  message  body  with  the  actual  -ata  set  being  transferred.  It 
was  further  recognised  that  this  Message  i.D.  information  is  both  necessary  and  sufficient  for 
satisfying  the  functional  requirements  of  a true  broadcast  routing  approach,  given  that  a 
complementary  level  of  associative  addressing  capability  exists  in  each  potential  recipient. 
Subsequent  study  of  the  possible  exploitation  of  this  unconventional  message  routing  approach 
revealed  it  to  be  advantageous  with  respect  to  the  DP  M inter-PE  communications  facility 
functional  design  objectives.  This  approach  was  adopted  in  the  busing  facility  design.  The 
detailed  operational  characteristics  of  this  message  routing/addressing  technique  , pear 
subsequently,  however,  the  functional  advantages  afforded  by  this  approach  are  listed  here  for 
prefatory  purposes- 

Broadcast  capability  is  inherent  in  the  addressing  method  since  messages  are  not 
directed  to  specific  recipients  by  the  transmitter  (i.e..  “source”  addressing 
instead  of  “destination*'  addressing) 

Message  overhead  is  minimized  since  no  destination  addressing  information  is 
required  in  the  message  content,  thus  information  transfer  efficiency  is 
increased 

Message-routing  determinations  associated  with  the  processes  of  system  design  and 
sy  stem  configuration  modification  is  simplified.  Primary  impact  in  this  area  is 
associated  with  the  routing  of  messages  from  a data  source  (task)  to  all  users. 
Usage  of  the  Message  Identity  Associative  Address  (MIAA)  routing  scheme 
greatly  simplifies  routing  assignments  since  no  destination  designation  is 
required  at  the  time  of  message  generation.  This  concept  is  valid  if  each  task 
is  allowed  to  generate  a single  data  set  of  aU  output  variables  generated  within 
that  task.  Each  user  of  any  portion  of  the  data  set  must  then  input  the  entire 
data  set.  possibly  incurring  a small  amount  of  storage  inefficiency.  This  mode 
ol  message  generation  and  delivery  is  also  desirable  because  it  offers  the 
greatest  expediency  in  message  delivery,  requiring  only  one  “pass'*  around  the 
“inis  control  loop’*  to  deliver  a given  set  of  data  to  ail  users  as  opposed  to 
splitting  a data  set  among  various  users  which  requires  multiple  messages  and 
thus  multiple  "bus-loop"  passes. 

Correct  and  eltivient  message  reception  control  within  the  Ph  is  hardware  facilitated, 
thereby  removing  some  ol  the  processing  burden  Irani  the  PE  control  software 
i Local  Executive  I 

Data  distribution  is  automatically  managed  by  ihc  associative  addressing  mechanism 
implemented  in  the  bus  interface  hardware  of  each  PE  and  therefore  does  not 
icquire  allocation  ol  PE  processing  to  this  function. 

DP  *.i  application  in  any  system  application  where  data  distribution  is  determined  by- 
dynamic  properties  ol  the  bus  data  traffic  is  permitted  and  facilitated. 

With  proper  implementation  practices,  the  approach  permits  minimum  bus  interface 
hardware  complexity  associated  with  address  recognition 
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The  Message  identity  Associative  Addressing  technique  is  a somewhat  fundamental 
departure  front  the  previously  -nvisioned  message  routittg  scheme,  but  its  impact  on  system 
design  is  advantageous.  The  scheme  is  an  inherent  broadcast  message-addressing  technique  which 
associates  the  identity  of  the  message  data  tor  data  source)  with  the  message  routing  function.  In 
effect,  the  technique  operates  by  each  processing  task  emitting  an  output  data  set  with  an 
associated  identity  header  onto  the  bus  ana  each  potential  receiver  (all  other  bus  users)  actively 
checks  the  header  (Message  I.D.)  to  determine  it  the  message  is  one  which  is  to  be  received. 
Assuming  that  each  PE  has  stored  the  "names”  of  all  messages  which  u is  interested  in  receiving 
(predetermine'!  during  system  design),  no  destination  routing  information  is  required.  The 
technique  requires  a single-address  broadcast-only  mode  of  bus  message  communication  ami  uses 
* the  message  format  shown  in  Figure  9.  This  format  allows  accommodation  of  up  to  1,024 
unique  messages  (source  data  sets)  in  the  DP/M  system,  an  arbitrary  choice  based  on 
compromising  maximum  (feasible)  system  message  population  requirements  with  minimum  bus 
interface  hardware  complexity  impact. 

Each  message  is  preceded  by  a header  which  contains  all  message  routing  and  control 
information.  The  header  length  is  chosen  equi  I to  the  basic  message  data  word  length  of  i ? bits 
for  reasons  of  hardware  simplicity  and  functional  capability.  The  message  header  is  subdivided 
into  the  following  control  fields: 

S-The  Message  Start  bit  is  fixed  at  a binary  data  ”1”  to  denote  the  beginning  of 
message  transmission  (required  for  Manchester  II  decoding  operation). 

H The  High  Priority  Message  tag  is  used  to  ale;  < the  message  recipient! s)  that  the 
message  requires  immediate  attention. 

GC  - The  4-hit  General  Control  field  allows  specification  of  special  ..ontrol/status 
information  which  further  defines  or  alters  the  interpretations  of  the  message 
data  being  transferred:  field  assignments  are  defined  and  interpreted  by  system 
software. 

MID  The  10-bit  Message  Identity  field  specific-,  the  identity  of  the  associated 
message  data.  This  field  is  used  to  establish  uexired  tiansmittcr/receiver  links 
during  message  data  transmission  (It  may  also  he  interpreted  as  tile  data 
source  address). 

- P The  Parity  bit  is  used  to  lotcr  odd  pants  ».  the  'leader  Uata  i f?  ruts*  for 
data-vahdity  checking  purposes 

The  message  header  is  immediately  succeeded  in  an  ct.J  oHr-j  Ui  sy  .iclmmi/ation  signal 
which  uniquely  delimits  the  header  content  fiom  the  remainder  of  the  message  data.  The 
insertion  of  this  Header  Sync  is  intended  to  increase  tin.  probability  of  d.tectmg  header  data 
errors  with  a simple  parity  technique,  thus  inciejsins  s/stem  mult  tolerance.  Simple  parity’ 
(one-bit)  is  included  at  the  end  of  each  word  of  a message  Previous  statistical  study  has 
indicated  that  this  level  of  error-checking  code  is  more  than  suftkienl  to  allow  reliable  dete.  lion 
of  bus  data  errors.  However,  since  the  validity  of  header  mlormaiion  nt  particular  importance 
to  correct  system  operation,  the  Header  Sync  is  used  to  reliably  identiiv  the  parity  bit  location 
if  data  bits  are  added  or  dropped  during  iicaJci  iraiisim-Mon  n . cption.  rhoefore.  the  Header 
Sync  should  be  a reliably  discriminated  signal,  unsu^cpi'bli-  to  .)<*rm.d  data  hit  errors. 
Consequently,  a unique  invalid  Manchester  bi  phase  data  patio. i (shown  m Figure  hi  was  chosen 
for  this  purpose  This  signal  is  represented  by  a “long"  low-leul  duration  of  1.5  data  bit  times 
followed  by  a "long”  high-level  duration  ot  1.5  bu  times,  nr  j id  <1  syu  signal  dotation  ol  3 
equivalent  data  bit  times. 


44 


50 


l-iinno  9.  Imer-Pt  Hus  Message  Slructtmvlorumt 


The  actual  data  content  of  tlu*  message  immediately  follows  t he  header  sync  signal. 
Message  transfers  are  block  oriented;  accordingly,  the  message  data  content  is  organised  into 
fixed-length.  16-bit  data  words  to  match  the  PI:  word-length.  A parity  bit  is  added  to  each  data 
word,  resulting  in  an  overall  1 7-bit  message  data  word  length.  Each  message  data  block  is  thus 
composed  of  an  integral  number  of  17-bit  data  words.  Each  message  may  contain  a variable 
number  of  data  words.  Global  bus  messages,  however,  can  be  optionally  limited  to  a maximum 
length  of  8 data  words  to  guarantee  global  communication  responsiveness  by  limiting  global  bus 
access  latency. 

It  i'  of  interest  to  note  that  no  message  length  mfoimation  is  fixed  into  the  message 
structure.  In  general,  individual  messages  are  nonvarying  in  length.  The  unique  length  of  each 
message  then  is  determined  at  system  design  and  this  information  is  “placed”  in  the  user  process 
(program).  In  exceptional  circumstances,  dynamic  message  length  information  can  be  inserted  as 
a part  of  the  messay.  data  content  and  handled  by  software  convention. 

Message  transmission  termination  is  denoted  by  an  end-oi -message  synchronization 
appended  immediately  after  the  final  data  word.  The  occurrence  of  this  Message  Sync  signal  is 
used  as  the  dynamic  cueing  mechanism  which  activates  and  controls  sequencing  of  the 
distributed  bus  control  logic  throughout  the  DP  M system.  If  a PE  has  no  data  to  transmit  when 
given  bus  control,  it  can  effect  “passing"  of  bus  control  by  emitting  a “zero-length”  message 
represented  by  an  isolated  Message  Sync  signal  Considerations  of  Message  Sync  validity 
requirements  dictate  the  use  of  a unique  invalid  Mulches  vr  hi -phase  sigiial  as  was  the  decision 
for  the  Header  Sync  signal  The  Message  Sync  sienal  ch-  sen  is  the  binary  complement  of  the 
Header  Sync  signal  fas  shown  earlier  in  Figure  8>. 

8.  Message  Reception  Control 

The  procedure  known  as  Message  Recef  tion  includes  the  primary  activities  of  Message 
Recognition  and  Selection,  and  Message  Vectoring  which  OvCtir  interna!  to  the  recipient  PEs. 

a.  Message  Recognition  and  Selection 

The  message  routing,  or  addressing,  scheme  cho-.cn  for  the  DP  M system  essentially 
removes  the  responsibility  of  determining  and  specifying  transmitter  receiver  links  jfrom  the 
transmitting  PL  to  the  receiving  PEtsf.  .as.  some  level  ol  associative-match  hardware  must  exist 
in  the  bus  interface  unit  of  each  PE  which  is  capable  of  storing  the  identity  (or  “address*')  of 
each  message  which  is  to  be  received.  The  message  rcvognition  logic  actively  scans  each  message 
header  appearing  on  the  bus  in  search  of  an  address  match. 

Ah  a matter  of  interest  here,  with  respect  to  message  .iddressing-routing  design  philosophy, 
it  is  important  to  note  that  any  message  reception  <.apabilny  within  a receiving  device  in  a 
multiplexed  data  system  requires  some  type  or  level  of  associative  memory  implementation.  The 
basic,  intrinsic  difference  between  the  logically  differentiated  routing  schemes  which  may  be 
described  as  '‘physical  destination,”  “logical  destination.”  or  “source”  addressing  is  manifested  in 
the  amount  of  associative  memory  required  tor  address-matching.  For  example,  simple  physical 
addressing  effectively  requires  a one-word  associative  memory  which  contains  the  physical 
address  of  the  receiver  Logical  destination  addressing  usually  requires  the  associative  storage  of  a 
relatively  small  number  of  multiple  logical  identities  which  the  receiver  may  assume.  Depending 
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on  implementation  and/or  the  number  of  addresses  allowed  per  receiver,  source-level,  or  message 
identity,  addressing  may  require  an  associative  memory  size  equivalent  to  the  total  number  of 
messages  in  existence.  The  immediate  design  implementation  implication  of  such  a scheme  is  that 
of  relatively  large  and  complex  “associative  memory”  hardware  requirements  in  the  Bill. 
However,  the  novel  implementation  scheme  proposed  herein  requires  u relatively  small  amount  of 
Bll1  hardware  associated  with  input  message  recognition,  less  than  that  required  for  a logical 
destination  name  scheme. 

LssenttaUy.  the. method  of  associative  addressing  used  “removes”  the  “associative  memory” 
hardware  normally  used  for  input  message  response  control  tin  the  form  of  “name  register" 
haul  ware)  from  the  BIU  into  a "dedicated"  portion  of  PE  memory.  This  area  is  known  as  the 
Message  Identity  Associative  Match  Map  and  is  equal  in  size  tin  bits!  to  the  maximum  nun>  r of 
unique  messages  required  by  a particular  system  application.  The  scheme  associates  each  bit 
within  the  “associative-response  map"  with  a particular  message  identity.  Tire  binary  value  of  the 
associative  bit  determines  message  selection.  The  message  population  thus  far  experienced  in  the 
DP  M baseline  system  is  in  the  64  to  128  region.  An  arbitrary  maximum  message  quantity  is  set 
at  ! .024  messages,  a choice  which  allows  a comfortable  system  ftexibtBty/growth  margin  while 
•bscrbiiig  a relatively  small  percentage  amount  of  the  PF  memory  ( 1 ,02^  bits  -*  64  wards). 
However,  it  is  important  to  note  that  the  usage  of  the  PE  main  memory  is  virtually  "free"  in  a 
hardware  economic  sense,  whereas  design  and  implementation  of  similar  associative  memory 
functions  within  another  unique  LSI  device  (the  BIU)  Is  relatively  expensive,  both  in  terms  of 
nonrecurring  development  and  recurring  hardware  procurement  costs. 

Another  consideration  to  be  noted  here  is  that  the  functional  implementation  proposed 
does  somewhat  degrade  the  processing  throughput  capability  of  the  PE  because  of  the  memory 
cycle-stealing  effects  of  the  associative-match  interrogation  operations  which  occur  coincidentally 
with  the  existence  of  each  message  header  on  both  the  Global  and  Local  buses:  however,  an 
analysis  of  the  baseline  DP/M  system  message  traffic  indicates  a memory  bandwidth  degradation 
of  approximately  0.1  percent-  Even  reasonable  worst-case  estimates  produce  an  anticipated 
maximum  degradation  ot  only  an  approximate  3 percent  utter  improbable  conditions.  This 
analysis  assumes  a 1.0-ps  memory  cycle  speed:  faster  memory  cycle  rates  are  considered  possible 
for  the  DP'M  PL.  further  rtductng  the  magnitude  of  this  already  insignificant  effect.  Clearly,  the 
practicality  of  the  scheme  is  a function  of  the  ratio  of  the  bus  bandwidth  (bit  rate)  and  resulting 
message  rate  versus  the  PL  memory  bandwidth.  Present  anticipated  design  parameters  are  well 
within  the  bounds  of  practicality  Jor  DP'M. 

h.  Mesxwie  Vectoring 


“Message  Vectoung”  refers  to  the  procedute  by  which  an  input  message  is  handled  within 
the  PL  as  die  message  data  is  extracted  from  the  bus.  Basically,  each  message  data  set  must  be 
passed,  or  “vectored.”  to  an  area  in  PL  memory  where  it  can  be  stored  for  later  use  by  an 
applications  software  process.  Dafa  buffering  is  required  since  the  DP/M  system  operates  in  a 
loosely-coupled,  asynchronous  mixle  with  respect  to  inter-process  communication.  Because  of  the 
data  rate  involved  and  PL  processing  overhead  considerations  in  message  transfers,  to  attempt 
handling  of  incoming  messages  on  an  interrupt-by-word  basis  is  impractical,  it  was  thus  evident 
that  an  autonomous  block-onvnted  Direct  Memory'  Access  (DMA),  cycle-stealing  capability  must 
.•xist  between  the  PL  Bus  Interface  Unit  (BIU)  and  the  PE  memory  to  minimize  program 
processing  intervention  during  input  message  data  transfers.  The  ir»!“thod  of  autonomous  DMA 
transfer  control  fhus  became  a subject  of  design  investigation. 


Conventional  autonomous  block-oriented  DMA  data  channels  require  processor  (program) 
initialization,  or  “set-up”  of  the  channel  before  beginning  data  transfers  to  memory.  The 
initialization  pt  cedure  allows  the  processor  to  specify  control  parameters  for  the  impending 
transfer  activity.  The  control  parameters  consist  of  a starting  memory  location  which  defines  the 
data  buffer  beginning  address  and  the  number  of  words  to  be  transferred,  or  buffer  length.  This 
initialization  process  is  required  per  message  received,  thus  associated  procer.mg  overhead  is 
directly  dependent  on  input  message  volume  and  the  amount  of  processing  required  to  determire 
the  desired  transfer  control  parameters  (i.e.,  the  data  buffer  address  and  length). 

In  addition  to  processing  overhead  considerations,  a more  constraining  performance 
requirement  is  placed  on  the  input  message  handling  capability  owing  to  the  nature  of  message 
trafTic  in  a total!)'  distributed  environment.  Essentially,  a stringent  message  throughput 
requirement  exists  (interna1  to  the  PE)  because  of  possible  “back-to-back"  message  situations 
where  multiple  messages  to  be  received  by  a single  PE  appear  contiguously  on  the  bus.  This 
potentially  troublesome  situation  is  further  compounded  by  the  fact  that  the  PE  interfaces  with 
two  asynchronous  bases  (Global  and  Local)  with  potential  simultaneous  message  activity 
occurring  on  each.  From  a worst-case  message  traffic  condition  analysis,  it  was  determined  that 
the  minimum  possible  time  between  message  completion  in  a recipient  PE  could  be  as  small  as 
42  microseconds.  This  critically  short  allowable  processing  response  time  is  further  reduced  to  an 
effective  2!  microseconds  in  the  potential  situation  where  processing  service  is  required  for 
simultaneously  competed  Global  and  Local  messages  with  a subsequent,  contiguous  local 
message  impending. 

The  above  observations  and  considerations  indicated  the  desirability  of  special  BiU 
functional  hardware  features  to  solve  the  problem  unless  the  hardware  complexity  incurred 
became  prohibitive.  Several  schemes  were  formuLted  and  considered.  The  initially  considered 
hardware  alternative  involved,  functionally  simple  double-buffering  of  the  BIU  input  channel 
buffer  address  and  length  registers.  This  appi  oach,  however,  allows  an  input  message  processing 
response  time  equal  to  only  the  length  of  the  subsequently  arriving  message:  thus,  unless  a 
minimum  message  length  of  10  to  12  words  is  somehow  enforced  in  the  system,  the  result  is  not 
satisfactory. 

The  approach  finally  deckled  upon  as  a viable  solution  to  the  message  processing  response 
time  problem  uses  a hardware-determined  message-vectoring  technique.  “Hardware  message 
vectoring”  describes  the  process  by  which  the  Bus  Interface  Unit  extracts  or  derives  a buffer 
storage  area  of  a message  in  PE  mcmor>  from  information  existent  in  the  message  being  received 
and  then  autonomously  transfers  the  message  data  content  to  this  area.  No  program  intervention 
is  required  in  setting  up  the  input  channel  before  each  transfer.  The  functional  implementation 
ol‘  the  technique  also  allows  the  BIU  hardware  to  validate  the  length  of  ihe  input  message  with 
its  expected  (correct)  length,  “known”  within  the  PE.  To  facilitate  message  processing 
subsequent  to  the  buffering  opeiation.  an  additional  functional  capability  was  incorporated 
within  the  BIU  which  permits  posting  of  each  received  message  identity  in  a first-in/ first-out 
♦ FIFO)  queue  located  in  PE  memory.  This  capability  greatly  reduces  Local  Executive  (LEX) 
processing  required  to  determine  received  message  identities  ex  post  facto.  The  functional 
processes  involved  are  described  in  detail  in  subsequent  section  relating  to  the  detailed  functional 
design  of  the  BIU.  The  overall  advantages  associated  with  the  adoption  of  this  technique  in  the 
DP/M  system  are  several.  The  primary  advantages  are  listed  below: 

Eliminates  LEX  message  processing  response  time  problem -no  interface  set-up 
operations  are  required  by  the  program,  and  received  message  identification 


queue  posting  is  automatically  maintained  by  the  BiU.  if  double  buffering  is 
required,  the  LEX  control  software  has  the  entire  sample  period  of  the  data 
being  double  buffered  to  set  up  the  alternate  Buffer  Address  in  memory. 

Reduces  LEX  overhead  significantly  the  BIU  hardware  automatic  message  vectoring 
performs  the  overhead  functions  which  otherwise  would  be  handled  by  the 
LEX.  This  overhead  corresponds  to  a significant  reduction  in  LEX  memory 
requirements  t = lOO  words  of  storage  estimated):  execution  time  savings  are 
also  appreciable.  This  results  in  increased  applications  task  processing 
throughput  capability  within  each  PE. 

Increases  efficient's  of  buffer  storage  space-  alternative  dynamic  buffer  allocation 
schemes  associated  with  LEX  message  buffer  handling  are  wasteful  of  memory 
in  that  each  buffer  size  must  be  of  a quantum  si.:e  equivalent  to  the  longest 
message  received  by  the  PE.  The  Hardware  Message  Vectoring  technique  incurs 
no  buffer  size  inefficiency. 

Message  length  validity  checking  is  eliminated  from  LEX  responsibility,  thereby- 
resulting  in  additional  software  overhead  savings. 

Hardware  Message  Vectoring  technique  requires  less  BIU  hardware  for 
implementation  than  any  other  alternative  scheme  investigated. 

The  operation  of  this  technique  caused  initial  concern  with  respect  to  memory  addressing 
validity  and  write-protect  ccnridentions  since  external's-  i.-ceivcd  data  is  used  directly  to 
determine  an  associated  memory  address.  This  concern  -va‘  eliminated  owing  to  the  address 
validity  assurance  afforded  by  the  message  “address"  recognition  mechanism.  The  message 
selection  mechanism  inherently  prevents  undetected  data  er.or  in  non-selected  message  identities 
from  becoming  an  agent  in  erroneous  memory  address  derivu.jn.  The  memory  addresses  derived 
and  accessed  by  the  BIU  during  message  data  . .put  will  correspond  to  correct 
software-determined  message  input  control  or  buffer  locations  such  that  the  accessing  of  random 
data  in  memory  to  be  used  as  buffer  control  informath  .1  is  prevented. 

9.  Fault-Tolerance  Considerations 

Since  the  integrity  various  system  Processing  functions  ts  dependent  upon  the  correct 
transmittal  of  deta  between  processes,  the  inter-PE  communication  facility  should  provide  the 
capability  to  monitor  all  data  communications  between  system  PEs  and  alert  the  system  upon 
the  detection  of  data  errors; faults.  Since  the  Global  communication  facility  (Global  bus)  is  the 
only  “centralized”  system  resource,  it  should  be  fault-tolerant  within  itself. 

DP'M  System  fault-tolerance  requirements,  as  applied  to  the  information  transfer  busing 
facility,  necessitate  the  existence  of  certain  fault-detection  mechanisms  within  the  BIU  of  each 
PE  to  facilitate  system  fault-tolerance  via  fault  detection/isolation  and  ensuing  system  software' 
recovery  techniques.  The  following  discussions  concern  each  unique  fault  detection  capability  to 
be  impleme  ’.ed  within  the  BIU  design  and  the  fault  condition  requiring  the  existence  of  each 
mechanism. 

a.  Bus  Message  I Data  Errors 

Bus  data  errors  may  be  caused  by  various  phenomena'  statistical  signal-to-noise  ratio 
induced  error  rate,  spurious  noise  bursts.  transmitteWreceiver  malfunction,  etc.  Such  errors  may 


V evidenced  l>v  various  manifestations  in  the  bus  data  stream.  With  the  bi-phase-encodcd 
asynchronous  data  transmission  technique  used,  such  errors  may  be  detected  as:  (!)  improperly 
encoded  data  representations.  C)  missing  or  added  data  bits,  or  (3)  data  content  error  (bit  value 
error).  I he  Bill  will  detect  any  ol  the  above  error  manifestations  in  a received  message  data 
stream  with  tile  following  mechanisms  to  ensure  input  data  content  validity: 


Biphase  encoding  patterns  received  in  the  input/receiver  section  of  the  BIU  are 
internally  compared  against  legal  Manchester  II  encoding  patterns.  This 
includes  both  data  and  unique  synchronization  signal  representations. 


Information  content  validity  is  chocked,  using  simple  odd-parity  checking  of  each 

16- bit  word  received  (i.e..  each  data  word  transmitted  on  a bus  is  received  as  a 

17- bit  quantity  in  each  receiver).  Parity  information  is  accumulated  during  the 
first  16  bits  of  each  received  data  word  and  is  compared  against  the  17th  bit 
of  each  data  word. 


Information  bit  presence  validity  is  checked  subsequent  to  the  reception  of  an  entire 
message  data  stream.  The  cheek  is  performed  by  testing  the  received  bit-string 
length  for  a modulo-17  length  (i.e..  an  integral  number  of  17-bit  words).  This 
validity  checking  measure  decreases  the  probability  of  nondetected  data  errors 
from  that  achieved  by  parity  checking  only. 

Bus  data  error  detection  of  the  types  described  above  are  performed  on  each  message  word 
(i.e..  both  Header  and  data).  Header  data  errors  are  discriminated  from  data  word  errors  in 
conjunction  with  BIU  activity  following  error  detection.  If  any  data  error  is  discovered  in  the 
content  of  the  message  header,  (lie  message  is  totally  discarded  as  a possible  candidate  for 
reception:  data  errors  detected  during  reception  of  the  “data”  content  of  a message  do  not 
change  the  normal  input  sequence:  i.e..  no  message  data  will  be  “thrown-away”  if  a message  data 
error  is  detected  earlier  in  the  message  reception.  It  is  intended  that  any  message  "dumping”  be 
left  to  the  discretion  and  option  of  the  Local  Executive  Control  (LEX)  or  the  applications 
programs  (data  users)  only. 


/>.  Messil/i e Protocol  Errors 

Owing  to  the  deterministic  nature  of  avionics  real-time  processing  requirements,  all  message 
definition  and  routing  requirements  can  be  determined  off-line  during  system  design  (e.g.,  during 
Process  Construction).  Therefore,  the  amount  r data  content  of  each  message  is  known  a priori 
and  this  knowledge  can  he  inserted  into  tic  E program  responsible  for  message  reception 
control/management.  The  BIU  automatically  « tracts  this  message  length  descriptor  for  each 
message  received  and  verifies  the  correctness  of  he  incoming  data  word  count  (message  length). 
If  a discrepancy  between  the  expected  message  length  and  the  received  word-stream  length  is 
detected,  the  message  is  termii  ted  at  the  short ei  length. 

A special  message-length  protocol  is  observed  for  all  messages  routed  via  the  Global  bus. 
All  Global  messages  are  required  to  be  limited  to  a maximum  data  content  of  eight  words  to 
ensure  a relatively  quick  system  response-time  (timeliness)  for  Global  Executive  control 
information  transmission  and  control  action  initiation.  Hardware  enforcement  of  this  protocol  is 
provided  in  the  BIU  by  detecting  and  inhibiting  an  attempted  violation.  Thus,  an  attempt  by  the 
IT  operational  program  to  transmit  a message  longer  than  eight  words  will  result  in  hardware 
detection  and  the  message  transmission  is  aborted  (i.e.,  no  transmission  is  initiated)  with  an 
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appropriate  interrupt  stimulus  generated  to  notify  the  processor  (program)  of  the  error.  Apparent 
in  this  design,  with  the  safeguard  mechanisms  above,  is  the  attempt  to  minimize  the  probability 
of  software-enor-induced  Global  message  length  protocol  violations  in  any  PE  (perhaps  a “mad” 
PE)  which  may  severely  affect  entire  system  operation. 

The  PE  is  notified  of  each  of  the  above  error  occurrences  via  hardware  flags  set  by  each 
detection  mechanism.  Under  program  control,  these  flags  can  either  by  interrogated  (read)  or 
allowed  to  generate  an  appropriate  interrupt  stimulus,  depending  upon  program  option. 

c.  But  Control  Error*/  Fomin 

Since  the  DP/M  bus  communications  facility  incorporates  a distributed  bus  control  scheme, 
each  PE  in  the  bus  control  “chain”  or  “loop”  must  actively  participate  during  its  designated 
access  slot  (time  slot)  to  maintain  proper  bus  control  circulation  throughout  the  DP/M  system. 
Bus  control  faults  can  occur  in  two  basic  modes:  bus  quiescence  -no  access  activity;  or  bus 
dominance  - monopolizing  or  incessant  activity. 

A bus  quiescence  condition  may  be  caused  by  “functional”  or  “physical”  discontinuities  in 
the  bus  control  chain.  A functional  discontinuity  is  attributed  to  a faulty  PE  (.for  internal 
reason)  which  fails  to  participate  (transmit)  during  its  allocated  time  slot.  Physical  discontinuities 
are  caused  by  failures  in  the  bus  common  itself  (e.g.,  broken  cable,  faulty  connection,  etc.) 

To  allow  recovery  from  a bus  quiescence  fault,  the  condition  must  first  be  detected. 
Detection  is  provided  in  the  BIU  for  both  Global  and  Local  buses  by  a Bus  Quiescence  Watchdog 
Timer  (BQWTl  implemented  in  each  bus  input  interface  section.  The  BQWT  measures  the 
duration  of  "no  bus  activity”  periods  (i.e.,  the  absence  of  bus  signal  transitions,  or  data 
bit-clock  1.  If  a “no  activity”  period  in  excess  of  a maximum  allowable  quiescence  time  value  is 
detected,  the  BQWT  causes  an  appropriate  interrupt  stimulus  to  be  generated  and  forces  the 
Global  output  access  mechanism  (including  the  Bus  Control  activity)  into  a disabled  state.  The 
latter  event  is  performed  to  bring  the  Communication  System  to  a known  state  (halted)  in 
preparation  for  ensuing  recovery  activity  which  b performed  under  the  control  of  a system 
software  recovery  monitor.  The  BQWT  time  period  b hardware-fixed  at  a period  of  time  which  b 
a function  of  anticipated  bus  control  response  delays  in  the  BIU,  bus  path  propagation  delays, 
system  initialization  related  timing  considerations,  and  error  detection  response  time 
requirements. 

A bus  dominance  condition  typically  can  be  caused  by  a faulty  BIU  output  interface 
section  which  acquires  access  of  the  bus.  not  necessarily  during  its  appropriate  allocation  time 
slot,  and  retains  access  with  incessant  transmissions  (e.g..  a “chattering”  PE*.  Hardware 
safeguards  are  provided  in  the  BIU.  as  described  previously  in  Subsection  lll.C.9.b  to  prevent 
dominating  conditions  caused  by  PE  program  execution  errors.  In  the  improbable  event  that 
these  hardware  safeguard  mechanisms  fail  or  the  BIU  output  section  (transmitter)  fails  in  a 
“chattering”  mode,  the  BIU  provides  a hardware  Bus  Dominance  Watchdog  Timer  (BDWT)  which 
essentially  monitors  the  length  of  each  independent  bus  access  period,  checking  for  a maximum 
length  message  violation.  The  BDWT  may  be  implemented  quite  economically  using  the  basic 
bit-count  logic  incorporated  in  the  BIU  message  input  section  for  input  message  assembly  and 
length  verification. 


If  the  BDWT  detects  a maximum  message  length  violation,  an  appropriate  interrupt 
stimulus  is  generated  and  the  BIU  Output  Control  Section  (including  all  Bus  Control  functions) 
is  forced  into  a disabled  state.  This  action  forces  the  bus  communication  facility  into  a known 
state  to  facilitate  recovery  actions  by  a software  routine  and  forces  (i.e..  attempts)  termination 
of  the  faulty  transmitter. 

Multiple  bus  user  access  errors  present  a particularly  troublesome  problem  in  detection. 
This  class  of  bus  control  laults/errors  can  be  caused  by  either  hardware  or  software  faults/errors. 
Hardware  faults  are  expected  to  typically  result  in  an  “out-of-position”  PE  which  attempts  to 
acquire  bus  access  in  another  PE  allocation  slot.  The  result  is  indeterminate  data  presented  on 
the  bus.  depending  on  the  electrical  coupling  characteristic  of  the  bus  interface  receiver/driver 
circuitry  used.  This  case  of  multiple  access  errors  will  typically  produce  an  eventually  detected 
bus  quiescent  condition  since  an  “out-of-order”  PE  will  not  honor  its  allocated  time  slot  when 
reached  in  the  system  bus  control  cycle. 

Unfortunately,  unique  failure  modes  can  arise  wherein  the  quiescent  condition  is  not 
introduced,  and  thus  non-detccted.  These  specific  situations  occur  when  a PE  assumes  an 
erroneous  bus  position  (or  access  slot  period  > which  is  a binary  submultiple  of  its  correct 
position  in  the  bus  control  chain.  For  example,  an  incorrect  position  of  “4”  will  overlap  a 
correct  position  of  “8.”  A more  extreme  example  is  the  situation  where  a PE  erroneously 
assumes  a position  value  of  “1“  which  causes  the  PE  to  transmit  during  every  bus  access  slot. 
Direct,  unambiguous  detection  of  these  particular  multiple  bus  access  situations  is  virtually 
impossible,  but  indirect  detection  can  be  accomplished  via  the  recognition  of  other  message/data 
errors  which  will  be  caused  by  the  multiple  access  contention;  i.e..  multiple  accesses  will 
invariably  result  in  continual  data  errors  (bad  parity  and/or  biphase  encoding),  and/or  message 
length  error,  and/or  Bus  Dominance  error  caused  by  non-discriminated  (non-valid)  message  sync 
signal  reception.  The  latter  of  these  indirect  error  manifestations  will  bring  the  bus 
communications  facility  to  a halt.  The  data/message  error  manifestations  can  provide  valuable 
information  to  the  GEX  (after  a certain  repetitious  threshold  is  surpassed!  about  the  fault's 
identity.  This  information  can  indicate  that  a dominant  condition  exists. 

d.  Bus  Interface  Fault  Detection 

The  bus  interface  unit  is  designed  to  allow  a full-duplex  mode  of  operation  to 
accommodate  self-test  message  transmission  and  simultaneous  reception.  This  “rebound”  test 
capability  can  be  exploited  under  program  control  to  verify  correct  bus  interface  operation  at 
the  small  expense  of  added  bus  traffic. 

e.  Fault  Detection  Mechanism  Control 

All  of  the  hardware  fault  detection  mechanisms  included  in  the  BIU  design  are  under  the 
control  of  PE  program  execution.  All  data/message  error  detections  are  recognized  by  the 
program  at  its  option,  depending  on  the  associated  interrupt  mask  setting  associated  with  the 
fault/crror-denoting  interrupt  stimulus.  Those  hardware  detection  mechanisms  which  affect  BIU 
status  (i.e.,  the  BQWT,  BDWT,  and  Global  Output  length  limiting  mechanisms)  are  also 
controlled  (enahled/disabledi  by  the  setting  of  their  respective  interrupt  mask  bit.  Thus,  it  is 
imperative  that  the  software  commands/routines  which  control  these  devices  be  structured  with 
fail-safe  interlocks  (internal  pass  word  access  codes,  etc.)  which  prevent  unauthorized  or 
erroneous  control  of  these  mechanisms. 
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f.  Redundant  Global  Buses 


It  has  been  previously  recognized  that  since  the  DP/M  system  Global  bus  is  the  only 
"central”  system  resource,  Global  fault-tolerance  should  be  especially  emphasized.  It  is  also 
recognized  that  either  catastrophic  Global  bus  failure  (i.e..  an  irreparable  failure/fault  which 
makes  the  Global  bus  useless)  or  certain  “removable”  faults  require  an  alternate,  redundant 
Global  communication  path  to  achieve  system  recovery.  Potential  inter-PE  data  busing  failure- 
modes  have  previously  been  identified  and  discussed.  Appropriate  provisions  have  been  made  in 
the  BIU  hardware  to  allow  detection  of  related  failures  and  consequently  alert  the  system  (via 
the  LEX)  of  their  occurrence  so  that  fail-safe  or  failure  recovery  procedures  can  be  performed. 
One  primary  important  fault-tolerance  design  aspect  deserves  expanded  attention  with  respect  to 
busing  facility  design.  This  area  of  concern  is  Global  bus  back-up  capability  if  the  Global  bus 
facility  fails  irreparably.  Irreparable  bus  failure  can  occur  as  a result  of  physical  failure/dainage  in 
the  communication  path  itself  (e.g..  electrical  interface  devices,  connectors,  cable),  or  particular 
hardware  software  failures  within  bus  users  can  effect  a bus  monopolization  condition  and  make 
the  bus  useless. 

The  above  class  of  bus  failures  cannot  be  tolerated  by  the  system  unless  some  facility  is 
provided  to  allow  “circumvention”  of  the  problem  in  order  to  allow  fault-tolerant  activities  to 
occur.  Clearly,  this  additional  facility  concept  is  required  at  the  Global  bus  level  to  prevent  a 
single  bus-failure  at  that  level  from  becoming  “catastrophic”  to  the  system.  Global  bus  backup, 
or  redundancy,  is  then  considered  as  a primary  fault-tolerant  design  objective  within  the  basing 
facility.  Global  bus  failure  recovery  via  switching  to  an  alternate  bus  can  be  effected  in  different 
manners.  For  purposes  of  hardware  simplicity,  the  originally  investigated  scheme  allowed  for 
constructing  a “quasi-global”  bus  from  the  set  of  local  buses  of  the  system  as  shown  in 
Figure  10.  If  the  global  bus  fails,  the  local  bus  nodes  in  each  Pfc  are  switched  to  form  a 
"daisy-chain"  bus  link  connecting  each  PE.  thereby  effecting  a "quasi-global"  bus.  However,  two 
distinct  disadvantages  were  discovered  associated  with  this  approach: 

• Global  bus  failure  recovery  must  be  accomplished  via  “back  door”  < local  buses) 
reconfiguration  control  information  passage  under  the  direct  control  of  each  and 
every  PE;  therefore,  the  construction  of  a quasi-global  chain  of  local  buses  requires 
that  ail  PEs  in  the  system  be  “well;”  i.e..  a failed  PE  which  cannot  perform  the 
necessary  local  bus  node  switching  (for  whatever  reason)  will  prevent  the 
quasi-global  configuration  from  occurring.  The  failed  PE  may  have  been  the  cause  of 
the  failed  global  bus. 

• Global  bus  failure  recovery  may  force  degraded  system  operation  because  of 
combined  Global.  Local  bus  traffic  of  entire  system  onto  a single  bus  facility.  (The 
dual-level  busing  structure  disappears.! 

During  the  analysis  of  the  above  global  bus  backup  concept,  it  became  apparent  that  an 
alternate,  or  redundant,  facility  of  some  type  must  be  incorporated  .in  the  busing  facility  design 
to  allow  global  bus  reconfiguration  control  information  passage  to  ail  PEs  if  a primary'  global  bus 
failure  is  detected.  Clearly,  the  operation  of  the  facility  should  not  depend  upon  or  be  affected 
by  the  operational  integrity  of  any  individual  system  element  (PE).  The  intuitive  concept  of 
redundant  global  buses  was  then  introduced  for  investigation  and  tradeoff  analysis. 

The  simple  redundant  bus  approach  is  shown  in  Figure  II.  This  approach  allows  for  the 
routing  of  doubly  redundant,  identical  global  bus  lines  to  every  PE  in  the  system.  This  approach 
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requires  an  increase  in  system  cabling  over  the  previous  scheme , but  the  increase  is  insignificant 
since  the  additional  cabling  is  in  the  form  of  twisted,  shielded -pair  transmission  line,  and  the 
previous  scheme  required  additional  cabling  between  affinity  group  dusters  (effectively  “pieces” 
of  a redundant  global  bus).  Design  questions  to  be  answered  with  respect  to  this  approach 
include  the  technique  of  alternate  bus  usage,  or  switchover,  control  and  Global  Bus  Interface 
functional  element  redundancy  requirements. 
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Functional  redundancy  desirability  versus  BID  hardware  complexity  tradeoffs  resulted  in 
the  design  choice  of  a single  Global  Bus  Interface  functional  hardware  element  with  the 
capability  of  switchablc  interfacing  with  redundant  physical  global  bus  paths.  Switchover  control 
requires  hardware  augmentation  to  allow  establishment  of  the  proper  bus  usage.  The  underlying 
philosophy  of  the  sought  approach  is  to  provide  backup,  or  failure  recovery,  capability  for  the 
global  bus  communications  path  only,  not  to  provide  each  Ft  with  Global  Bus  Interlace 
failure-recovery  at  its  local  level  |i.e.,  failure  recovery  techniques  are  required  at  the  system  level 
only,  not  at  the  individual  resource  (Ptl  level  |.: 

The  above  mentioned  Global  bus  redundancy  philosophy  led  to  the  search  for  a functional 
redundancy  design  approach  which  would  offer  satisfactory  Global  bus  reliability  while 
maintaining  abbreviated  hardware  complexity  additions  in  the  BIU-  As  a first  step  toward 
formulating  such  an  approach,  the  responsibilities  of  a Global  bus  redundancy  management 
function  section  of  the  BIU  were  identified  to  be: 

Provide  a redundant  bus  “listening”  capability  to  detect  alternate  bus  activity  t fault 
recovery  commands) 

Detect  a “switchover”  situation 

Select  the  alternate  Global  bus  as  the  valid  input  source  and  switch  the  Global 
reception  section  to  the  alternate  (backup!  bus 

Provide  switching  of  the  Global  interface  output  to  either  of  the  redundant  Global 
bus  paths  under  software  control. 

The  redundant  Global  bus  management  scheme  adopted  has  resulted  from  the 
aforementioned  functional  design  considerations  as  well  as  a somewhat  speculative  but 
conservative  future  LSI  implementation  impact  consideration.  The  approach  is  represented  in  the 
functional  block  diagram  of  Figure  1 2.  The  primary  underlying  system  level  fault-tolerance 
assumption  reflected  in  this  approach  is  that  all  Global  bus  failure  recovery  activity  will  be 
initiated  and  supervised  by  an  intelligent  software  system  entity,  the  Global  Fxecutive  (GKXi 
|i.e..  the  detection  of  a failure  condition  requiring  use  of  the  backup  bus  and  the  ersumg  system 
recovery  commands  (via  the  backup  bus)  will  be  left  to  the  discretion  of  the  GFX  software 
only}.  The  redundancy  management  logic  performs  the  following  activities  involved  in 
“catastrophic”  primary  Global  bus  failure  recovery. 

When  a recovery  action  is  decided  upon  by  the  GFX.  it  issues  a “switch  to  alternate  bus" 
command  (predefined,  dedicated  message  identity  i over  the  alternate  bus.  Transmission  access  to 
the  alternate  bus  by  the  GFX  PF  is  effected  by  previously  commanding  the  redundancy 
management  logic  to  switch  the  Global  bus  interface  transmitter  to  the  alternate  bus  with  a 
“Switch  Global  Output”  l O instruction.  Upon  reception  of  a valid  “switch  to  alternate  bus” 
command  message  on  the  alternate  (standby)  Global  bus.  the  redundancy  management  logic  in 
each  PF.  BIU  (including  the  GFX  PI  I will  automatically  switch  (connect)  the  Global  bus  input 
interfuse  to  the  alternate  (now  primary'!  bus.  and  all  subsequent  communications  will  be 
performed  via  the  new  bus  connection.  This  input  switchover  action  will  terminate  any  current 
message  input  activity  in  each  PF  bus  interface  by  forcing  a “reset”  of  the  associated  input 
interface  control  logic. 

Now  that  the  GFX  has  the  system  “listening”  to  the  backup  bus.  it  can  transmit  recovery 
dvtion  commands  in  a normal  Global  communication  mode.  The  procedure  follow'd  for  recovery 
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will  Ik*  similar  lo  a system  initialization  control  sequence.  Dcpeiidmi!  mi  tlu*  detected  nature  of 
llu  lailun*.  each  II*  may  Ik*  indis ulually  commanded  lo  connect  Us  out |>u l lo  ilk*  newly 
appointed  primary  bus  lor  diagnosis  purposes,  or  all  1*1  s can  Ik*  "switched”  in  unison  with  a 
sinde  command  communicated  via  (lie  newly  appoinled  Global  bus. 

I acli  lime  a bus  svvilehovei  activity  is  initialed,  llu*  roles  ol  the  two  physical  (Ilobal  buses 
ale  reversed  li.e..  "primaiy’  or  “alternate”).  Therefore.  during  a (ilobal  bus  tailure  recovery 
procedure,  the  Inis  coni  ituiral  ion  can  Ik*  svviiehed  more  than  once,  it  required.  This  capability  is 
intended  to  prevent  “lockup"  ol  the  backup  Inis  if  a “mad"  I’l  which  caused  the  primary  bus 
t'ailme  i s switched  onto  the  backup  bus  dining  the  reemetv  process.  When  this  occurs.  tlieKiHX 
in. is  lorce  switchover  to  the  previous  conlipm.ition  with  the  tailure  now  icmoved  lo  the 
"st.iiulbv  " Inis.  Ibis  approach  will  accommodate  all  modes  of  sinple  t.uluies  in  the  ( ilobal  bus 
laeihls 


I he  (ilobal  Inis  reiltindancy  maiiapemenl  scheme  descubed  above  appeals  satisfactory  in 
meet  tit)!  (ilob.il  Inis  reliability  coals  with  a viable.  Iow-!i.iidwaio-complcxil>  implementation  in 
the  mi  . 

D.  BUS  INTERFACE  UNIT  FUNCTIONAL  DESIGN  DESCRIPTION 

I lie  Hits  Intcilace  Unit  (Hil  l provides  the  hardware  elements  requited  to  implement  the 
bus  coiuiminciation  facility  desitm  requirements  and  concepts  previously  described.  The  major 
functional  elements  implemented  within  the  baseline  MIC  dcsipn  are  shown  in  lupine  I .V  Owinp 
to  coiisiileration  ol  actual  functional  and  performance  characteristics  required  of  the  Hill  at  both 
■the  (ilobal  and  l ocal  levels,  and  the  desirability  of  hardware  simplicity  commonality  within  the 
BIU,  it  was  rccopm/ed  that  the  same  functional  elements  could  be  replicated  lor  both  (ilobal 
and  Local  interlaces,  with  onl\  minor  diflerenccs  which  will  In*  identified  in  the  following 
description  of  each  functional  partition  ol  the  BIU. 

1 Bus  Data  I ranslation 

I lie  Hus  Data  Translation  lunctional  element  is  responsible  tor  providiup  interface 
compatibilitv  between  the  biphase-encoded  serial  data  transmission  Inis  lauliiy  and  the  Non 
Return  to  Zero  (NR/.i  parallel  data  orientated  1*1  . Ilns  functional  eleincut  also  peilorms 
inteurits  checks  on  the  mcominp  seiial  data,  llu*  Ibis  Data  I ranslation  tuiKtional  element  is 
composed  o|  two  major  sublunctional  elements  dcsctibed  below. 

a iiiphasc  Data  Decmlcf Assembly / Verification 

I Ins  siihttinctional  element  ot  the  Mil  decodes  the  In -phase-encoded  Inis  data  into  binary 
NR/  data  and  Inf-clock  information  I he  incomiii)'  serial  data  stieam  is  converted  into  parallel 
Di  l'it  word  format  for  transmission  to  the  !*l  meuiorv  Die  im.  online  data  is  abo  scanned  lot 
recognition  ol  the  uni(|ue  synchronization  patterns  and  notilies  llu  l$us  Input  Channel  Uontrol 
and  Message  Reception  Control  functional  elements  o|  then  iKcurtence.  Also  performed  m this 
section  is  input  data  validity  cheekim'  which  verities  enco-.t*  d data  tormat.  data  word  lenyili.  and 
data  word  parity  eoiiectness.  Detected  eriors  ,uc  ttolilied  to  the  litis  Input  Channel  Conttol 
luiicltoiial  element. 
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k.  Update  Data  Encode!  Trmmmtt 


This  subfunctional  element  converts  the  parallel  1 6-bit  data  words  extracted  from  the  PE 
memory  by  the  Output  Channel  Control  Functional  element  into  a serial  bit-stream  of 
bi-phascencoded  data  transmitted  onto  the  bus.  Parity  is  generated  for  each  data  word  and 
inserted  as  the  last  bit  in  a 17-bit  transmitted  word.  This  section  also  generates  the  unique 
bi-phase  synchronization  signals  as  commanded  by  the  Bus  Access  Control  functional  element 
(for  “passing*  bus  control)  or  the  Bus  Output  Channel  Control  functional  element  (for 
terminating  data  transmission  or  header  denoting). 

2.  Message  Reception  Control 

The  message  reception  control  functional  element  is  composed  of  two  primary  functional 
sui-elemcnts.  Message  Selection  Control  and  Bus  Input  Channel  Control. 

a Message  Selection  Control 

The  Message  Selection  Control  functional  element  interrogates  each  message  header  as  it  is 
accumulated  from  the  bus  in  the  Bus  Data  Translation  functional  element.  This  element  “maps” 
the  message  header  (which  is  the  Message  Identity)  into  a physical  PE  address  within  the  Message 
Input  Associative  Match  Map  (M1AMM)  space  in  PE  memory  (refer  to  the  procedure  shown  in 
Figure  14).  The  control  logic  then  extracts  the  word  addressed  in  M1AMM  and  tests  the  proper 
associative  response  bit  associated  with  the  received  header  (re.,  the  Message  f.D.  is  mapped  into 
a physical  bit  address  in  PE  memory).  Detection  of  a “set”  bit  (logic “I”)  indicates  that  the 
message  is  to  be  received  by  the  PE:  detection  of  a “reset”  bit  (logic  “0”)  indicates  that  the 
message  is  not  relevant  to  the  PE.  and  thus,  ensuing  message  data  should  not  be  input  The 
correct  associative  match  map  information  is  assumed  to  have  been  placed  in  the  ItlAMM 
memory  location  at  time  of  program  initiahzation.  Positive  detection  (recognition)  is  relayed  to 
the  Bus  input  Channel  Control  functional  element  to  initiate  the  data  input  sequence. 

k.  §m  Input  Channel  Control 

The  Bus  Input  Channel  Control  functional  element  assumes  responsinility  for  message  data 
input  to  the  PE  memory  subsequent  to  notification  of  input  enable  detection  from  the  Message 
Selection  Control  section.  The  procedure  by  which  message  input  is  achieved  is  shown  in 
Figure  IS  and  follows  the  sequence  below: 

The  message  header  now  resident  in  the  Input  Data  Register  (IDR)  is  input  to  the 
PE  memory'  location  currently  addressed  by  the  Input  Queue  Pointer  (IQP). 
The  identity  of  the  received  message  is  thus  placed  into  a FIFO 
(ftrst-in-firsl-out)  queue  of  modulo  (8)  words  in  a dedicated  portion  of  PE 
memory.  This  action  provides  automatic  hardware  queue  posting  of  input 
message  identities  to  be  subsequently  scanned  and  processed  by  the  processor 
Local  Executive  software  (LEX)  at  its  convenience  and  throughput  capability, 
thus  eliminating  inlet rcp»  response  execution  time  overhead,  which  would  be 
incurred  subsequent  to  each  individual  message  received.  (The  IQP  is  later 
incremented  at  message  termination.) 

The  message  header  in  the  IDR  is  now  “mapped”  into  a physical  PE  memory 
address  corresponding  to  its  appropriate  location  in  a pseudo-dedicated 
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(reserved)  contiguous  portion  of  PI:  memory  referred  to  as  the  Message  Buffer 
Vector  space.  Hie  contents  of  this  location  are  fetched  and  used  to  directly 
specify  the  predetermined  starting  location  of  the  message's  data  buffer  area 
in  memory.  Note  that  the  Message  Buffer  Vector  space  may  be  a maximum  of 
1,024  words  in  length  (corresponding  to  a maximum  permissible  1,024 
messages  in  the  system).  However,  any  given  system  application  will  require 
“dedication”  of  only  a portion  of  this  memory  space  within  a given  PE  equal 
to  the  number  of  messages  to  be  input  by  the  particular  PE.  This  results  in 
“scattered”  dedicated  or  pre-defined  locations  within  this  possible  IK  word 
space.  Use  of  non-dedicaled  space  within  this  area  is  at  the  option  of  the 
system  software  linking-loader  operation.  It  is  important  to  note  also  that 
access  validity  into  this  address  space  by  the  Bus  input  Channel  Controller  is 
guaranteed  by  the  preceding  message  input  selection  activity  which  effectively 
ensures  the  validity  of  the  header  address  if  a response  match  is  found  fi.e., 
the  M.I.D.  associative  matching  technique  is  actually  a fault-tolerance 
mechanism  associated  with  this  Bus  Interface  Unit  memory  addressing 
function). 

The  contents  of  the  Message  Bui.  . Vector  word  fetched  in  the  above  step  are  now 
used  as  a re  memory  address  which  corresponds  to  the  first  location  in  the 
message  data  buffer  area.  The  confer.:  of  this  initial  word,  by  convention, 
specifies  the  correct  message  length  and  is  fetched  by  the  Bus  Input  Channel 
Control  logic  and  loaded  into  the  input  Length  Register  (ILR). 

The  input  channel  is  now  ready  to  transfer  incoming  data  words,  as  ’hey  arrive 
serially,  and  place  them  contiguously  into  memory,  incrementing  the  Input 
Address  Register  (IAR)  and  decrementing  the  Count  Register  as  each  word  is 
transferred.  Transmission  is  terminated  with  the  occurrence  of  either  a 
message  sync  signal  detection  on  the  bus,  and/or  a Length  Register  content  of 
“zero.”  The  first  of  the  conditions  to  occur  will  cause  termination  at  that 
point;  if  the  two  events  are  not  “simultaneous,”  an  error  condition  is  flagged 
via  an  interrupt  to  the  processor.  If  the  termination  events  are 
“simultaneous,”  an  appropriate  “input  message  received”  intem.pt  is 
generated.  Message  termination  also  results  in  the  incrementing  of  the  Input 
Queue  Pointer  (1QP). 

Two  interrupts  can  be  generated  by  the  successful  completion  of  the  input  data 
transfer.  A norma)  “input  message  received”  interrupt  is  generated  subsequent 
to  every  message  completion.  A “high-priority  message  received”  interrupt  is 
generated  after  the  completion  of  a message  which  contains  a “true” 
high-priority  tag  bit  contained  in  the  message  header. 

A timing  analysis  of  the  above  described  input  message  transfer  sequence  reveals  that 
single-word  buffering  in  the  BIU  input  data  section  is  sufficient  to  maintain  data  validity 
between  receipt  of  the  message  header  and  final  usage  of  its  information  content  in  “setting-UD” 
the  input  channel  for  data  transfer.  Maximum  time  which  may  be  experienced  for  this  sequence 
is  nine  memory  cycles  for  the  local  bus  in  a worst  case  memory  access  timing  situation 
(simultaneous  global  and  local  input  activity).  The  next  data  word  is  loaded  into  the  buffer  17 
microseconds  later,  a much  longer  time  than  represented  by  nine  memory  cycles  «9 
microseconds)  under  presently  envisioned  bus  and  memory  bandwidth  performance  figures. 
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Figure  16.  MU  Mcreory  AMocition  Map 


The  above  message  input  actrvit.es  require  the  use  of  reserved  or  dedicated  areas  of  PE 
memory  as  described  above.  Tentative  assignments  of  these  areas  in  memory  and,  thus,  definition 
of  the  address  generation  required  of  the  associated  message  input  com.  ?i  hardware  are  shown  in 
the  memory  map  diagram  of  Figure  16. 

Tne  above  described  functional  capabilities  implemented  in  the  Message  Selection  Control 
and  Bus  Input  Channel  Control  hardware  sections  offer  a quick-reaction,  high  speed,  efficient  (in 
terms  of  conserving  processor  throughput)  input  message  handling  capability  within  the  PE, 
which  allows  it  to  adapt  to  and  perform  proficiently  in  the  envisioned  asynchronous, 
loosely-coupled  DP/M  bus  communications  environment. 


68 


3.  Mnufe  Trans  million  Control 

Hie  Message  Transmission  Control  section  performs  the  tasks  of  retrieving  output  message 
data  from  PE  memory  and  transferring  them  to  the  Biphase  Data  Encode/Tnnsmit  subfunctional 
element.  The  operation  of  this  channel  is  analogous  to  that  of  a conventional  autonomous  DMA 
computer  I/O  channel.  Hie  channel  is  setup  and  initiated  under  program  command  by  loading 
the  Output  Address  Register  (OAR  I with  the  address  of  the  contiguous  data  block  buffer  to  be 
output.  By  convention,  the  first  word  in  this  buffer  area  defines  the  actual  data  buffer  length. 
This  control  data  is  extracted  and  loaded  into  the  Output  Length  Register  (OLR).  The  actual 
output  message  data  block  follows,  with  the  initial  word  in  this  block  being  the  message  header. 
(Refer  to  Figure  1 7 for  a graphical  description  of  this  operation.)  The  channel  then  oversees  the 
process  of  receiving  each  successive  word  as  the  previous  word  is  emitted  to  the  bus.  Single-word 
buff  .ring  of  memory  output  data  is  used  to  maintain  a continuous  serial  data  stream  output  to 
the  bus.  At  the  completion  of  the  buffer  transfer,  the  Bus  Output  Channel  Controller  directs  the 
output  transnutter  to  issue  a message  sync  signal  and  informs  the  processor  of  the  buffer 
completion  via  an  interrupt.  , 

Also  provided  in  this  functional  element  is  the  busing  facility  fault-tolerance  mechanism 
which  detects  attempted  violation  of  the  eight-word-maximum  Global  message  protocol.  Upon 
detection  of  an  attempted  violation  (OLR  loaded  with  value  greater  than  eight),  the  Bus  Output 
Channel  Controller  aborts  the  output  initialization  sequence  and  generates  an  interrupt  stimulus 
to  the  processor  to  denote  the  occurrence  of  the  attempted  violation. 

4.  Bus  Access  Control 

The  Bus  Access  Control  functional  element  controls  the  access  of  the  PE  data  transmission 
section  to  the  bus.  Access  control  is  based  on  a hardware  implemented  round-robin  circular 
priority  sequence  which  allows  the  PE  to  control  the  bus  when  its  appropriate  allocation  slot  is 
detected.  Up  to  2S6  bus  access  slots  can  be  accommodated,  thus  permitting  a satisfactory  degree 
of  supercommutation  of  available  bus  access  slots  in  envisioned  system  applications  (Ies6  than  32 
PEs).  This  control  section  is  fragrant  initialized  by  software  commands  which  define  the 
“length”  of  the  bus  (the  PE’s  access  control  period  in  units  of  allocation  time  slots)  and  the 
current  “position”  of  the  control  slot  in  the  bus  control  chain.  The  functional  supercommutation 
of  bus  allocation  time  slots  among  the  various  users  is  accommodated  by  this  bus  control 
element  as  shown  by  the  exemplary  bus  system  in  Figure  18.  This  characteristic  is  considered 
important  in  reducing  bus  access  latency  time  for  “high-priority”  bus  users. 

When  the  bus  control  logic  recognizes  that  its  time  slot  has  begun,  it  either  enables  an 
output  data  transfer  to  begin  or  effects  “passing”  of  bus  control  to  the  next  allocation  slot  by 
commanding  the  data  transmitter  section  to  emit  a Message  Sync  signal,  depending  on  whether 
the  Output  Channel  has  been  activated  by  the  program.  This  output  control  logic  is  also 
responsible  for  observing  the  intermessage  gap-timing  requirement  of  2 microseconds  minimum 
before  beginning  data  transmission. 

Also  included  in  the  Bus  Access  Control  functional  element  are  the  “watchdog-timer” 
mechanisms  provided  for  bus  facility  fault  detection.  These  mechanisms  are: 

Bus  Quiescence  Watchdog  Timer  measures  time  between  bus  activities  (i.e., 
“no-signal”  time),  if  a maximum  allowable  quiescent  time  of  50  microseconds 
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is  exceeded,  an  appropriate  interrupt  stimulus  is  generated  and  all  Bus  Access 
Control  functions  are  disabled. 

Bus  Dominance  Watchdog  Timer  measures  length  of  each  individual  Global  memage 
transmission.  If  a message  transmission  of  greater  than  8 data  words  is 
detected,  an  interrupt  stimulus  is  generated  and  all  Bus  Access  Control 
functions  are  disabled. 

$.  ftocessor/Memory  Interface  Control 

This  functional  element  of  the  BIU  performs  the  necessary  control  operations  associated 
with  providing  interface  protocol  compatibility  between  the  BIU  and  the  internal  PE  data 
exchange  bus  (i-BUS)  which  interconnects  each  functional  unit  of  the  PE.  All  data/command 
exchange  between  the  processor/memory  and  the  BIU  are  accomplished  via  this  internal  bus.  The 
P/M  Interface  Control  section  contains  the  logic  associated  with  decoding/ recognising  BIU 
control  instruction  commands  from  the  processor  and  effecting  their  execution  within  the  BIU. 
A list  of  BIU  command/control  instructions  is  shown  in  Table  4.  This  functional  element  also 
contains  the  hardware  elements  required  to  retain  and  present  the  various  BIU  interrupt  stimuli 
to  the  processor  interrupt  input  via  the  l-BUS.  The  section  performs  program-controlled  masking 
of  each  separate  interrupt  and  provides  protocol  compliance  with  the  processor  interrupt-related 
operations.  HU  interrupt  stimuli  are  listed  in  Table  5. 

6.  Redundant  Bus  Management 


The  Redundant  Bus  Management  (RBM)  functional  element  of  the  BIU  is  responsible  for 
providing  the  necessary  control  elements  required  to  interface  a single  BIU  (and,  thus,  single  PE) 
to  dual-redundant  (pair)  Global  busses.  The  control  icjic  of  thi*  functional  element  acts  as  a 
passive  monitor  with  regard  to  the  designated  alternate,  or  “back-up,”  bus.  This  monitoring 
activity  includes  “listening”  for  a valid  predetermined  (hardware)  “switchover”  command 
occurring  on  the  alternate  bus.  For  purposes  of  fault-tolerance  enhancement,  the  reliability  of 
this  detection  process  may  be  increased  with  the  use  of  various  validity-checking  codes  or 
“pump-up”  schemes  applied  to  the  formatting  and  transmission  of  the  “switchover”  command 
message.  The  required  validation  technique  will  then  be  implemented  in  the  RBM  functional 
element  hardware.  When  a valid  “switchover”  command  message  has  been  recognized,  the  RBM 
then  switches  the  BIU  Bus  Input  Channel  over  to  the  alternate  bus  so  that  all  future  memage 
receptions  are  extracted  from  the  newly  established  bus  connection.  This  action  forces  the  Bus 
Input  Channel  logic  to  abort  any  input  message  activity  in  progress  at  the  time  of  “switchover” 
command  detection  and  “resets”  all  message  input  control  logic  functions. 

In  addition  to  the  above  monitoring  process,  the  RBM  functional  element  of  the  BIU 
provides  the  capability  to  switch  the  BIU  Bus  Output  Channel  to  either  of  the  Global  busses 
under  program  < processor)  control.  This  switching  activity  can  be  performed  between  bus 
connections  as  many  times  as  directed  by  program  command.  Thus  “primary”  and  “alternate” 
Global  bus  identities  can  be  established  dynamically  and  interchanged  as  many  times  as  required 
during  system  operation. 

E.  BUS  INTERFACE  UNIT  IMPLEMENTATION  CONSIDERATIONS 

implementation  requirements  of  the  previously  established  and  discussed  functional 
characteristics  of  the  BIU  were  next  investigated  to  assess  the  impact  of  these  characteristic 
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TABLE  4.  MU  COMMANDS 
(INSTRUCTIONS) 

1.  Load  Global  But  Control  Parameters 
(But  Length  and  Position) 

2.  Load  Local  But  Control  Parameters 
(But  Length  and  Petition) 

3.  Activate  Global  Output 

4.  Activate  Local  Output 

5.  Load  Global  Interface  Status 

6.  Load  Local  Interface  Status 

7.  Load  Global  Primary  Interrupt  Masks 

8.  Load  Local  Primary  Interrupt  Masks 

9.  Enable  Global  Output  Activity 

10.  Enable  Local  Output  Activity 

11.  Disable  Global  Out  pi  < Activity 

12.  Disable  Local  Output  Activity 

1 3.  Switch  Global  Output  to  Alternate  Bus 

1.  Send  Present  Global  Bus  Position 

2.  Send  Present  Local  Bus  Position 

3.  Send  Global  Input  Queue  Pointer 

4.  Send  Local  Input  Queue  Pointer 

5.  Send  Global  High-Priority  Interrupts 

6.  Send  Local  High-Priority  Interrupts 

7.  Send  Global  Low-Priority  Interrupts 

8.  Send  Local  Low-Priority  Interrupts 

9.  Send  Global  Interface  Status 

10.  Send  Local  Interface  Status 

1 1 . Send  Global  Primary  Interrupt  Masks 

12.  Send  Local  Primary  Interrupt  Masks 

Note: 

Global/Local  Status  Information  contains: 

• Bus  Interface  Enabled/Disabled  condition 

• Output  Channel  Busy/Available 

• interrupt  Mask  register  contents 


TABLE  S.  BIU  INTERRUPTS 

GhWHglsflMy: 

1.  Global  high-priority  message  received 

2.  Global  bus  quiescent 

3.  Global  bus  dominated 

4.  Global  message  length  violation 

5.  Globa)  message  header  error 

6.  Global  message  word  count  error 

7.  Global  message  word  length  error 

8.  Global  message  parity  error 

9.  Global  message  encoding  error 
Gtabal  Law-fMwity: 

1.  Globa)  message  received 

2.  Global  transmmton  completed 
UcM  high  Priority : 

1.  Local  high-priority  message  recrived 

2.  Local  bus  quiescent 

3.  Local  bus  dominated 

4.  Local  message  length  violation 

5.  Local  message  header  error 

6.  Local  message  word  count  error 

7.  Local  message  word  length  error 

8.  Local  message  parity  error 

9.  Local  message  encoding  error 
Lacal  Law -Priority: 

1.  Local  message  received 

2.  Local  transmission  completed 

Note:  Interrupts  are  listed  in  order  of 
decreasing  priority 


requirements  on  actual  hardware  design.  Of 
primary  importance  in  this  design  investigation 
was  the  effect  of  each  BiU  functional  element 
on  LSI  device  complexity.  One  of  the 
underlying  criteria  of  the  DP/M  Processing 
Element  design  was  the  compatibility  ot  the 
functional  design  with  LSI  device  technology 
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capabilities  in  both  the  near  future  (mid-to-late  I ‘>7()‘s)  and  early  1980  time-frames.  Thus,  design 
simplicity  at  the  functional  level  was  sought  and  avored  in  many  of  the  tradeoff  areas  discussed 
previously. 

I.  Bit'  Register  Level  Description 

To  allow  determination  ot  the  practicality  and  extent  of  LSI  implementation  achievable 
with  the  functional  design  given,  a preliminary  register  level  design  of  the  BIU  wits  performed. 
Tins  level  of  hardware  design  describes  each  basic  hardware  functional  element  required  to 
implement  each  BIU  functional  element  and  thus  allows  approximate,  but  representative, 
quantitative  estimates  of  1.SI  device  complexity  requirements.  Also  defined  are  the  interface 
sigiiu'  requirements  ot  each  functional  element  to  allow  representative  estimates  of  device  I/O 
signal  (pinout)  requirements. 

Hie  register  level  design  of  each  Bus  Interface  Unit  functional  element  is  shown  in  the 
register  level  block  diagrams  of  Figures  1 9 through  27.  Note  that  the  message  selection  control 
and  bus  input  channel  control  functional  subelements  have  been  shown  coliecti'  ely  in  the 
message  reception  control  register  level  description  because  of  their  directly  related  and 
somewhat  common  hardware  functional  requirements.  Also,  the  major  hardware  sequence  control 
functions  required  in  the  Message  Reception.  Message  Transmission,  and  Bus  Access  Control 
functions  are  represented  only  at  the  block  1 * For  complexity  estimating  purposes,  a state 

flow  (flow  chart)  description  which  describe  the  procedure,  or  state  sequence,  required  of  the 
control  logic  elements  ts  given  for  each  ot  i cse  control  functions  in  Figures  21.  23.  and  25. 
respectively.. 
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Figure  19.  Bus  Interface  Translation  Register-Level  Block  Diagram 
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IDLE  UNTIL  A MESSAGE  HEADER  IS 
RECEIVED 


LOAD  ASSEMBLED  HEADER  INTO 
BUFFER; INITIALIZE  MESSAGE  SYNC 
WAIT  TIME  COUNTER 


IF  ANY  ERROR  EXISTS  IN  HEADER. 
GENERATE  INTERRUPT 


IF  HEADER  INDICATES  H.P. 
MESSAGE.  SET  H.P.  FLAG 


* 

GENERATE  MIAMM  MEMORY  ADDRESS 
(13  BITS)  FROM  HEADER  BITS  (6-1 1), 
STARTING  AT  LOCATION  IFCO  (HEXA- 
DECIMAL) 


F'gurv  21  Mcvajee  Reception  ( ontruMer  Flo*  Diagram  (Sheet  I of  M 
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FETCH  INPUT  BUFFER  LOCATION  AND 
PLACE  IN  INPUT  ADDRESS  REGISTER 


FETCH  BUFFER  LENGTH  WORO  FROM 
INITIAL  BUFFER  LOCATION  AND 
PLACE  INTO  INPUT  LENGTH  REGISTER 


Figaro  21.  Message  Reception  Controller  Flow  Diagram  (Sheet  3 of  6} 
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MESSAGE  INPUT  TERMINATED  BY 
EITHER  I UR  DECREMENTED  TO  ZERO 
OR  MESSAGE  SYNC  OCCURRENCE 


IF  DATA  ERROR  EXISTS  IN  DATA 
WORD.  SET  APPROPRIATE  FLAG 


WRITE  DATA  WORD  INTO  CURRENT 
MEMORY  BUFFER  LOCATION 


INCREMENT  BUFFER  LOCATION 
DECREMENT  WORD  COUNT 
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Figure  21.  Mewigr  Reception  Controller  Flow  Diagram  (Sheet  6 of  b) 
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Figure  22.  Menage  Transmission  Control  Register-Level  Mock  Diagram 


IDLE  UNT1L“ACTIVATE  OUTPUT- 
INSTRUCTION  IS  EXECUTED  AND 
OUTPUT  CHANNEL  IS  ENABLED 


LOAD  OPERAND  (OUTPUT  BUFFER 
ADDRESS)  OF  "ACTIVATE  OUTPUT* 
INSTRUCTION  INTO  OUTPUT 
ADDRESS  REGISTER 
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READ  INITIAL  MESSAGE  WORD 
(HEADER)  FROM  OUTPUT  BUFFER 


PLACE  HEADER  INTO  OUTPUT  DATA 
BUFFER  REGISTER:  INCREMENT 
MEMORY  ADDRESS 


Figure  23.  Meviage  Ttw&nu  mom  ControNer  Fkm  Diagram  (Shed  I of  4) 
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I — MESSAGE 
LENGTH  VIOLATION 
INTERRUPT  STIMULUS 
0 —OUTPUT  ACTIVE  FLAG 


T 
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FETCH  CONTENTS  OF  INITIAL 
BUFFER  LOCATION  (BUFFER  LENGTH) 


LOAD  BUFFER  LENGTH  DATA  INTO 
OUTPUT  LENGTH  REGISTER; 
INCREMENT  MEMORY  ADDRESS 


IF  MAXIMUM  MESSAGE  LENGTH 
VIOLATION  INTERRUPT  IS  ARMED 
AND  BUFFER  LENGTH  GREATER 
THAN  8 IS  READ  FROM  MEMORY, 
ISSUE  INTERRUPT  AND  ABORT 
OUTPUT  ACTIVITY 


Figure  23.  *5 e*»ge  Tnuwmiwkm  Controfcr  Flow  Diagram  (Sheet  2 nf4| 


PLACE  HEADER  WORD  INTO  OUTPUT 
SHIFT  REGISTER  AND  WAIT  FOR  BUS 
ACCESS  CONTROL  TO  BEGIN  OUTPUT 
(INITIALIZATION  PROCESS  NOW 
COMPLETE) 

HAS  BUS  CONTROL  BEEN  OBTAINED? 


OUTPUT  ENABLE  STATUS  CHECKED 
HERE  REPEATEDLY  IN  THE  EVENT 
OF  PROGRAM-CONTROLLED 
DISABLING  OF  OUTPUT  ACTIVITY 


FETCH  NEXT  SUBSEQUENT  OUTPUT 
MESSAGE  DATA  WORD  FROM 
CURRENT  BUFFER  LOCATION 


PLACE  DATA  WORD  IN  OUTPUT 
REGISTER.  INCREMENT  BUFFER 
ADDRESS.  DECREMENT  BUFFER 
WORD  COUNT 


Figure  23.  Mcuage  Trammivaon  ControHe*  Flow  Diagram  (Sheet  3 of  4| 
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AS  EACH  COMPLETE  DATA  WORD  IS 
SHIFTED  OUT,  PLACE  NEXT  OATA  WORD 
INTO  OUTPUT  SHIFT  REGISTER 


TERMINATE  DATA  FETCH  ACTIVITY 
WHEN  WORD  COUNT  IS  DECREMENTED 
TO  ZERO 


WHEN  FINAL  DATA  WORD  IS  SHIFTED 
OUT,  ISSUE  MESSAGE  SYNC  SIGNAL. 
DEACTIVATE  OUTPUT  CHANNEL.  AND 
GENERATE  COMPLETION  INTERRUPT 
STIMULUS 


Figure  23.  Mevuge  Innuntwot  Cur  trotter  Floe-  Diagram  (Shed  4 of  4| 


NRZ  DATA  CL.K 


Figure  24.  Bus  Access  Control  Register-Level  Block  Diai 


IDLE  STATE 


CURRENT  MESSAGE  ACTIVITY  (IF  ANY) 
FINISHED?  IF  NOT,  CHECK  TO  SEE  IF 
PROGRAM  CONTROL  HAS  DICTATED  BUS 
ACCESS 

IS  BUS  TRANSMISSION  ACTIVITY 
ENABLED? 


DECREMENT  BUS  POSITION  REGISTER 


IS  BUS  TRANSMISSION  ACTIVITY 
ENABLED? 


IS  IT  MY  TURN  TO  TRANSMIT?' 


IF  YES,  RE-INITIALIZE  BUS  POSITION 
REGISTER  WITH  CONTENTS  OF  BUS 
LENGTH  REGISTER.  OTHERWISE.  GO  TO 
IDLE  STATE 
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FigMre  25.  8u%  Uccv.  twMroller  Flow  Diagram  I of  4) 
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'OUTPUT\n 

.ENABLED^^"" 


IS  BUS  TRANSMISSION  ACTIVITY 
STILL  ENABLED? 


'GAP  TIME 
^EXPIRED, 


ALLOW  MINIMUM  GAP  TIME  TO  EXPIRE 


OUTPUT 
PENOING 
FLAG  = I 


HAS  AN  OUTPUT  BUFFER  BEEN 
INITIATED /INITIALIZED 


1 — OUTPUT  ENABLE 
0 — OUTPUT  PENDING  FLAG 


IF  YES.  ENABLE  TRANSMISSION  TO 
BEGIN  AND  RESET  OUTPUT  PEND|f«G 
FLAG 


OUTPUT  MESSAGE  SYNC 
BPR — 1 — BPR 


IF  BUFFER  INITIALIZATION  HAS  NOT 
PREVIOUSLY  OCCURRED.  ISSUE 
MESSAGE  SYNC  SIGNAL  ONLY  AND 
DECREMENT  BUS  POSITION  REGISTER 


fipt  25.  H*t  faces*  Cn utility  Row  PiapMi  IShert  2 of  4| 
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-- 


, \ /•*£;•■*  "T&gSi^ 


© 


ENABLE  SO  i&  TIMER 


1 


RESET  50  pS  TIMER 

~r~ 

Pto 


IF  NO  BUS  ACTIVITY  IS  DETECTED, 
ENABLE  QUIESCENCE  COUNTER 


HAS  MAXIMUM  ALLOWABLE 
QUIESCENCE  TIME  EXPIRED 


IF  YES.  GENERATE  BUS  QUIESCENCE 
INTERRUPT  AND  O! SABLE  ALL  TRANS- 
MISSION ACTIVITY.  OTHERWISE 
CON  TINUE  QUIESCENCE  DETECTION 
PROCESS 


IF  BUS  ACTIVITY  IS  PRESENT.  RESET 
QUIESCENCE  TIMER 


Fipuc  25.  Bn  Acccb  CmtraScr  FWw  Dopant  iSheH  4 of  4) 


Fifurr  26.  Proceator/Memory  Interface  Contra)  Renter-Level  Block  IBapram 





It  is  important  to  reiterate  here  that  the  design  of  the  ovetiB  Bus  Interface  Unit  allows  the 
use  of  a collection  of  common  replicated  BIU  functional  elements  to  implement  both  Global  and 
Local  bus  interfaces.  This  characteristic  is  very  important  and  advantageous  with  respect  to 
detailed  hardware  implementation  considerations  as  will  be  discussed  in  Section  VI.  Thus,  the 
BIU  register  level  design  described  herein,  with  the  exception  of  the  Redundant  Bus  Management 
functional  element,  reflects  the  iiardware  actually  required  to  interface  the  PE  with  each  level  of 
bus  connection  and  simply  is  replicated  for  both  levels  (Global  and  Local)  of  bus  connections. 
Figures  28  and  29  show  the  register-level  interconnections  of  these  functional  elements  requir'd 
to  configure  the  overall  Global  and  Local  Bus  Interfaces,  respectively. 
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Hardware  lumptruly  Estimates 


The  register  level  design  description  of  the  BIU  functional  elements  alto  *'s  a satisfactory 
estimate  of  device  implementation  complexity  requirements  to  be  performed.  A logic  “gate”  was 
chosen  as  a standard  unit  of  measure  of  device  complexity;  however,  the  interpretation  of  an 
actual  “gate”  in  terms  of  actual  functional  and  physical  attributes  is  somewhat  variable, 
depending  on  the  semiconductor  technology  used  in  the  device  implementation.  Since  the 
characteristics  of  present  generation  bipolar  TTl.  technology  logic  devices  are  universally  known, 
each  BIU  functional  element  was  sized  in  units  of  TTL-equivalent  gates  as  an  interim  jgandard: 
this  choice  keeps  the  sizing  estimates  from  becoming  too  biased  toward  any  given  LSI 
technology  and  also  aftords  a unit  of  measure  which  may  be  relatively  easily  converted 
quantitatively  into  appropriate  units  of  measure  for  the  various  alternative  LSI  technologies. 

The  actual  complexity  estimate  resuits  for  the  BIU  functional  elements  are  given  in 
Table  b These  estimates  were  formulated  from  the  following  sizing  quiddities  and  assumptions: 

Where  applicable,  catalog-advertised  TTL  device  gate  counts  were  used 
straightforward  to  estimate  similar  BIU  functions 

Each  hardware  register  assumes  conventional  “flip-flop”  device  implementation  with 
6 gates  required  per  bit  of  register  storage 

All  sequential  control  functions  were  assumed  to  be  implemented  with  conventional 
encoded-state  sequential-controller  techniques 

Manchester  H'NRZ  data  code  conversion  (encode/decode I hardware  estimates  reflect 
a conservative  best  “guesstimate”  of  worst-case  implementation  based  on 
examination  of  possible  alternative  implementation  techniques  (e.g.. 
frequency-independent,  or  frequency-dependent! 

A “blanket”  estimate  factor  of  20  percent  was  used  to  estimate  the  amount  of 
ancillary  logic  elements  t clock-logic  drivers,  clock  gaters.  etc.!  required  in  each 
functional  element  implementation  as  a function  of  the  amount  of 
control-only  logic  utilized  in  the  functional  element. 

There  is  one  area  of  potential  significant  BIU  complexity  reduction  worthy  of  note.  If 
overall  system  fault-tolerance  considerations  allow,  the  BIU  device  complexity  can  be  reduced  to 
approximately  1.525  gates,  a reduction  of  475  gates  lor  approximately  25  percent  of  overall  BIU 
complexity!  by  implementing  the  BIU  as  a half-duplex  instead  of  full-duplex  data  transfer 
facility.  This  functional  modification  would  remove  the  capability  to  use  the  BIU  in  a “self-test" 
mode  since  simultaneous  message  transmission  and  reception  could  not  be  facilitated. 
Recommendation  of  this  modification  cannot  be  established  until  the  actual  impact  of  the  more 
complex  design  on  LSI  implementation  considerations  are  more  well-defined. 

F.  BIU  SIMULATION  MODELING 

A functional  simulation  model  reflecting  the  current  BIU  register  level  design  was 
developed  as  a portion  of  the  PL  functional  simulator.  This  model  accurately  represents  the 
operation  of  the  BIU  hardware  at  a functional  register  level.  The  BIU  model  is  modularly 
structured  as  the  integration  of  a set  of  BlU-evcnt  models,  each  of  which  is  a FORTRAN 
subroutine  representation  of  a discrete  functional  operation.  Lach  event  is  modeled  in  terms  of 
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TABLE  6.  BUS  INTERFACE  UNIT 
FUNCTIONAL  HARDWARE  COMPLEXITY  ESTIMATES 


Functional  Element 

h irdware  Complexity 
(1  'L-equivalenl  gates) 

1 

Message  Output  Control 

620 

\ 

Message  Input  Control 

H5«r 

,t 

Hus  Access  Con  trol 

401 

4 

Processor/ Memory  Interface 

217 

5 

Hus  language  Translation 

too 

(i 

Redundant  Hus  Management 

2X7 

loial  Mill  Complexity  21  1 ) ♦ 2( 

2 ) ♦ 2(  4 » ♦ 2t  4 ) * .It  5 ) ♦ i 

- 4,f*0 1 gales 


the  effect  of  tlie  event  on  the  functional  registers  of  the  Bill  hardware.  The  models  arc  driven 
by  exogenous  events  and  also  interact  with  other  PH  functional  element  models  (c.g..  the  PH 
memory)  in  the  performance  of  particular  Bill-related  activities. 

Basically,  the  BIU  model  is  segregated  into  two  primary  functional  activities:  Message 
Input  and  Message  Output.  Haeii  major  activity  is  then  subdivided  into  a collection  of 
register-level  events  associated  with  the  performance  of  the  activity  during  PE  operation. 
Figures  .10  and  .11  show  the  event  How  structure  of  the  Message  Input  and  Message  Output 
activities,  respectively.  Each  event  model  is  essentially  duplicated  for  both  Global  and  Local  bus 
activities,  with  minor  deviations  occurring  in  a few  event  models  where  G/L  operational 
characteristics  differ.  The  structural  and  operational  characteristics  of  the  PR  Functional 
Simulator  are  described  in  Section  VII  and  will  not  be  discussed  further  herein.  It  should  be 
mentioned  that  the  modular  structuring  of  the  BIU  activity  model  along  with  each 
hardware-dependent  timing  characteristic  expressed  in  parametric  form  allows  flexible  definition 
of  the  BIU  functional  operation.  The  value  of  this  attribute  has  been  proven  during  BIU  design 
and  model  development. 

I'he  BIU  functional  design  was  validation-tested  with  a test  program  written  in  DP/M  PE 
assembly  language  code  and  executed  by  the  PH.  Functional  Simulator.  This  program  manipulates 
a set  of  exogenous  events  (predefined  messages)  defined  speeifically  for  testing  the  BIU  behavior 
under  a comprehensive  set  of  test  conditions  reflecting  the  inter-PR  bus  communications 
environment.  The  following  BIU  functional  performance  parameters  and  conditions  were  tested 
by  this  program: 

All  BlU-related  I/O  instruction  executions 
Message  Reception  control 
Message  Selection 
Message  Length  Determination 
Message  Buffer  Location  Determination 


Preceding  page  blank 


Figure  30.  Giohal/Local  Message  Output  Event 
Scheduling  Flow  (Sheet  I of  2) 


Input  Message  Data  Transfer 

Input  Message  Da ta/ Length  Error 
Detection 

High-priority  Message  Recognition 

BIU  Interrupt  Generation  (all 
stimuli) 

Bus  Access  Control  Sequencing 
(including  Bus  "passing”) 

Global  Output  Length  Violation 
Detection/Prevention 

Concurrent  Global/Local  Input/ 
Output  activities  (all 
permutations) 

Worst -case  Input  Message 
Occurrence  Timing  (back-to- 
back  receptions) 

Input  Message  Queue  Posting  (with 
and  without  message  errors) 

Bus  Quiescent  Watchdog  Timer 

Bus  Dominance  Watchdog  Timer. 

This  simulation  testing  has  shown 
satisfactory  operational  performance 
characteristics  of  the  BIU  functional  design 
(thus  making  it  a viable  candidate  for  use  in 
the  DP/M  system  environment)  as  well  as 
validating  the  correct  operation  and  interaction 
of  the  various  BIU  functional  elements.  Simula- 
tion results  of  particular  interest  include  those 
which  indicate  processing  time  degradation 
owing  to  memory  cycle  stealing  effects  caused 
by  message  reception/transmission.  The 
simulation  test  cases  present  an  extremely 
heavy  bus  loading  per  unit  time  '•condition 
which  may  be  considered  "worse  than  worst- 
case”  for  normal  system  operation.  Even  so,  it 
was  shown  that  the  interaction  of  BIU  memory 
cycle  stealing  activities  associated  with  this 
rather  exorbitant  bus  loading  and  program 
(instruction)  execution  resulted  in  a total 
processing  time  degradation  of  approximately 
only  9 percent.  Thus,  processing  time 
degradation  concerns  due  to  BIU  functional 
characteristics  were  dispelled.  Also  of  particular 
interest  with  respect  to  BIU  design 
performance  were  the  simulation  results  which 
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associative: 


Figure  U.  <>(uhaI/i.4K%;)t  Message  Input  l*\cnl  Soheiiuliiu:  Flow 


showed  s.ilisijv tor>  performance  < > t the-  input  message  *. * »i» t r< <1  iiiili.ili/.ition  junction  under  tile- 
worst  case  condition  ol  smnilt.uieous  initialization  in-put  I. utter  setup i procc-dutes  in  both  Global 
and  Local  iiiterl.ii.es  with  .ittend.mt  memon  \ c !e  sidling  con.'luls  WuN  vase  input 
initiali/ation  time  under  this  worst  ease  condilion  i S nivrosc-condsi  was  shown  li>  he  well  within 
that  allowed  In  hus  trallic  protocol  il~  muiosecords  data  word*  assuming  .1  minimum  uiemor> 
handwidlh  capability  ol  I million  memon  „ycles  -c-vond 

G.  AREAS  OF  FURTHER  INVESTIGATION 

File  present  Bus  Interlace  lint  design  dev.r  bed  previously  in  this  section  is  intended  as  a 
tentative  baseline  approach  to  a linai  lumtionil  an  I reenter  level  desum  wlinh  may  be  lurther 
tailored  to  represent  a net  ter  match  to  1)1*  M s\ stein  requirements  as  these  reijuirements  become 
identified  and  or  more  well-known  and  understood  It  is  assumed  .ami  re  commended  that  lurther 
investigative  ellorts  will  use  the  tuiktn.uul  simulalon  tools  provided  in  conmiktion  with  this 
design  ellort  t e < siipp  >r t the  design  refinement  and  validation  activities 

In  the  course'  ol  formulating  the  present  system  design,  several  areas  ol  analytical  tradeoff 
decisions  were  made  m an  el  tort  to  minum/e  hardware  complexity  and  to  satisfy  system 
tunetional  requirements  with  intormation  available  at  the  time  ol  investigation  Willi  proper 
extended  simulation-aided  investigative  eliort  these  tentative  design'  parameters  may  be 
continued  or  lurther  relmed  modified  to  better  meet  empirically  determined  system 
requirements 

Those  tuiutional  design  parameters  winJi  are  primary  candidates  tor  lurthei  analytical 
and  or  empirical  investigation  uulude  the  following 

I liminatioii  ot  lull-duplex  Bll  operation  the  oadeott  encountered  is  reduced  Bll 
hardware  complexity  at  ti  e expense  ol  sacrificing  Bll  "’self-test ’’’  capibility 
Investigation  should  an.dv/e  the  true  value  or  utility  ot  the  sell-test  feature 
and  the  actual  quantitanve  impact  ot  Us  attendant  device  complexity  on  IS! 
device  fabrication 

A tentative  Gl.u'al  message  length  limit  has  bean  chosen  at  S words  as  an  analytical 
compromise  between  actual  (ilob.d  message  length  requirement'  and  bus 
access  latency  lor  the  muioritx  o|  (rlobal  transmission'  lespe'  lallv  with  respect 
to  Global  executive  tuiictioiisi  I uithe>  investigation  should  not  only 
determine  the  best-suited  quantitative  value  <>l  this  parameter  but  should  also 
investigate  it  leqmremenl  exists  i<>  lu-tity  the  inclusion  ot  program-controlled 
length-limitation  to  bettei  accommodate  perhaps  widely  varying  system 
application  requirement'  <at  the  expense-  ot  added  hardware  complexity  1 

Queuing  ol  input  message  utc-uotics  has  been  arbitrarily  lixed  at  eight-words  lie. 
IMQ  lengtb.  ot  ' uordsi  he  correctness  ot  thi'  cjuantitative  choice  can  only 
be  v Titled  through  e'lensv.  siimdalio'-,  ot  me-sasic  activity  encountered  in 
many  various  apphc.itioi  c \ddiiionallv  the  tunetional  integrity  ol  the 
queueing  structure  chosen  can  be  examined  during  the  same  simulation 
procedure  and  it  required  additional  queueing  operational  te.it ures  can  be 
ihcorporaied  into  the  desi-aii  tea.  pr"eiam-c'<ntrc'lle-d  eueue-si/e  hardware- 
queue  oveitlow  detection  prevent  ion  eic  1 I’resent  design  parametei'  were 
chosen  m a compromise  ellort  !■>  meet  .malUkul  ree]uiremc-nts  with  minimum 
hard  vare  complexity  llowc-ver  luttlui  empiiical  imi'i  >\ition  mav  reveal  a 
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requirement  tor  added  hiiKtioii.il  capabilities  at  tin-  expense  of  Bll'  hardware 
complexity 

Bll’  function  mentors  allot. a! ion  required  hx  the  present  design  uses  fixed 
(hardwired!  portions  o|  1*1  memory  Actual  usaue  experience  via  extended 
situation  max  ie\eai  a desirihiltty  to  allow  program  control  or  selection  ot 
mcmoiy  are..s  allocated  to  Bit  luiKtions  t Again  .it  the  expense  ot  added  Bll 
hardware  complexity  i 

Actual  or  unique  pnonti/ation  re<|iiuenients  ot  Xiloh.|  l.oeal  Inis  users  max  exceed 
those  accommodated  In  the  Baseline  Inis  contiol  algorithm  and  or 
supereomnnilation  c.ipahilitx  'I  such  is  the  case,  it  can  he  revealed  only 
lluoiigh  en.pirK.il  investigation 

-\n v degrading  influences  on  PI  processing  pertormanee  caused  by  the  BIl's 
luiKOonal  usage  ot  PI  memory  can  he  exposed  uni}  hx  exercising  actual 
applications  code  (programs!  via  simulation.  It  any  unexpected  hut  significant 
liegrading  influences  are  found,  it  max  he  decided  to  change  the  physical 
design  ol  the  Bll  hx  providing  a separate,  unique  memorv  to  provide  the 
associative  memorv  t unctions  required  in  the  design  ol  the  message  input 
control  element 

Once  the  actual  cost'  ot  the  Bll  hardwaie  devices  are  ascertained,  it  max  he  desirable  to 
adopt  an  alternate  technique  *»t  redundant  global  Inis  management  The  present  design 
recommendation  is  a result  ot  stressing  overall  Bll'  hardware  simplicity  However,  it  Bll' 
hardware  costs  are  sigmficantlv  small  enough  with  respect  to  overall  DP  \1  system  cost 
ohiCc lives,  it  max  he  desirable  trom  the  viewpoint  ot  application  flexibility  and  extend . to 
implement  redundant  bus  management  with  an  individual  Bll'-per-hus  jpproaclt.  fins  approach 
would  essentially  require  replication  ot  the  functional  hardware  required  to  interlace  a given  bus 
to  the  PI  lor  each  bus  required  in  the  system  te.g  three  Bll  s would  he  required  for  the 
baseline  sxstemi  with  the  elimination  ot  the  requirement  lor  a unique  Redundant  Bus 
Management  lundum  This  approach  otters  little  it  any  lunetioiul  impact  on  system  design 
• vperjtion  System  level  redundant  bus  management  techniques  would  not  lequire  any  alteration. 
Hie  only  turiction.ii  impact  on  Bll  operation  is  the  possible  requirement  for  adding 
programmable  enabling  ms.ihhne  ol  individual  bus  interlace  message  reception  activity  after  a 
faulty  bus  is  detected  and  isolated  Die  primary  physical  implementation  impact  is  that  the  Bll’ 
must  he  modularly  partitioned  to  allow  a "Bll -per-hus"  system  construction.  In  jddition.  each 
Bll  would  require  1 "programmable"  mentitx  capability  tor  all  characterizations  ot  each 
individual  mis  interlace  leg  PI  memory  allocation  lor  separate  input  message  queues,  interrupt 
assienments  etc  i during  sxstem  initiali/.dion.  tlnis  introducing  additional  hardware  complexity 
to:  the'  Bll  design  However,  it  properly  implemented,  the  approach  may  realize  added  flexibility 
benefits  by  permitting  a variable  number  ot  system  buses  per  application  with  a greater  number 
ol  topologie.il  configurations  allowed 

It  should  be  emphasized  here  that  the  above  identified  candidate  areas  ot  further  design 
investigation  via  accumulation  01  empnic.d  data  (by  simulation t do  not  necessarily  suggest 
tunction.il  design  deficiencies  in  the  present  baseline  BIT  design  They  do.  however  relate  to 
areas  ol  desien  tradeoffs  recoimized  in  the  piesent  functional  design  process  with  tradeoff 
decisions  made  primarily  in  favor  ot  minimum  hardware  requirements,  based  on  analytical 
investigation  with  little,  it  any.  emp.rieal  data  available  to  aid  in  the  decisions.  It  is  thus 
recommended  that  the  next  phase  ol  'esign  validation,  ic.  validation  with  empirical  data 
slathering  via  ipphcalion  simulation  experiments,  be  performed  bet  ore  final  B!l'  design 
formulation  and  acceptance 


SECTION  IV 

PROCESSOR/MEMORY  DESIGN 


This  section  summarizes  the  recommended  design  specifications  tor  the  I)P  M PI  processor 
and  memory  modules.  An  internal  PI-  bus  facility  (the  l-BUSl  is  described  as  is  its  potential  use 
for  aiding  hardware  and  software  maintenance  functions.  The  design  approach  for  these  modules 
was  guided  by  a number  of  objective,,  with  primary  emphasis  on  identifying  and  incorporating 
those  computational  features  required  for  a large  segment  of  different  avionic  processing  system 
applications.  Likewise,  a parallel  effort  was  made  to  stress  simplicity . modularity,  standardization 
of  interfaces,  and  low-risk  hardware  features  that  would  result  in  a cost-ettective  design  and 
implementation.  The  design  effort  had  as  its  goal  the  definition  of  a standard  reprogrammable  PI 
which  was: 

Computationally  capable  so  as  to  be  suitable  for  a wide  range  of  avionic  processing 
problems 

Simple  enough  for  the  processor  to  be  fabricated  as  a low-cost  module. 

These  requirements  were  reviewed  in  light  of  previous  Air  Force  avion1,  processor 
requirements  analysis  efforts  and  current  trends  in  commercially  available  technologies  and  design 
concepts  The  general  PL.,  characteristics  satisfying  the  first  requirement  are 

1 6-bit  processor  architecture 

250  KIP  (thousand  instructions  per  second)  processor  performance 

8K  word  memory  module  per  PI-.. 

The  second  requirement  for  a low-cost  implementation  appears  attainable  based  on  existing 
semiconductor  technologies  and  their  current  expected  rate  of  advancement,  and  is  discussed  in 
Section  VI. 

Items  considered  in  the  design  specification  of  the  processor  memory  were: 

Elimination  of  the  need  for  instruction  code  modification  at  run  time  (e.g..  dynamic 
shift  counts) 

Addition  cl  a short  instruction  format  for  high-usage  instructions  to  conserve 
program  space  and  to  improve  execution  speed 

Inclusion  of  certain  uninterruptible  basic  read  modify  w'nte  instructions  (clear  bit. 
set  bit.  test  and  set  bit.  and  store  through  mask)  to  prevent  incorrect  action  as 
the  result  of  an  interrupt 

Identification  of  a need  tor  signed  multiply  and  divide  for  numerical  data  processing 

Definition  ot  a common  ii.ter-PI.  data  bus  (l-BUS)  to  provide  for  internal 
communications  between  the  Processor.  Memory.  BIL  and  I ()  modules. 

Investigation  of  a simplified  Processing  Element  maintenance  control  panel  and  A(il 
concept  implementuble  through  the  use  of  the  l-Bl:S. 

A.  PROCESSOR  FUNCTIONAL  ARCHITECTURE 

The  following  paragraphs  describe  the  functional  architecture  ot  the  DP  M processor.  The 
term  “functional  architecture"  is  used  to  describe  thu»  set  of  computer  capabilities  available  to 


the  programmer  and  is  exemplified  by  the  programmable  registers,  il.it a types.  and  instruction 
set  I'lie  design  ol  the  DP  M processor  t olio  wed  a top  down  approach,  i.e..  the  design  started 
with  a review  ol  existing  and  protected  digital  avionic  processing  applications  and  identified 
various  alternatives  to  he  candidates  lor  incorporation  into  the  DP  M processor  desmn.  The 
material  presented  in  this  subsection  is  an  overview  ot  the  lunction-J  architecture  ol'  the 
processor  and  some  ol  the  design  tradeotls  identified  during  the  design  etlort.  The  items  that  are 
summarized  include  the  processor  organization.,  instruction  complement,  addressable  registers, 
and  data  types  The  results  ot  sample  instruction  usage  analysis  are  presented  as  are  the  interrupt 
and  initialization  requirements  tor  the  processor 

I'he  DP  M processor  is  a In-hit.  two's  complement,  eight  register  file  architecture  The 
processor  provides  the  necessary  ! mictions  to  perform  arithmetic,  logical,  sinlt.  and  data  transfer 
operations.  Opeiands  lor  the  execution  ot  instructions  are  obtainable  from  the  register  file  and 
program  memory  and  results  aie  pla  ed  into  either  tile  register  rk\  program  memory,  processor 
status  word,  or  translerred  as  input  output  data 

I . \ddressahle  Registers 

file  DP  M PI  processor  has  an  eight-register  general  icgister  file  with  two  registers 
designated  lor  the  program  counter  <P<  i and  the  interrupt  stack  pointer  tlSPl.  These  general 
registers  can  be  used  as  uccumul  it  ;rs.  indexes,  bases,  and  or  to  hold  temporary  variables.  This 
register  tile  configuration  was  selected  after  a careful  review  analysis  ol  alternative  approaches  t-_ 
the  addressable  register  configurations. 

The  alternatives  examined  tor  the  addressable  registers  included  both  accumulator  register 
file  organizations  Many  processor  designs  have  used  an  accumulator  and  extended  accumulator, 
with  and  without  additional  index  registers  A more  recent  approach  is  to  have  a file  of  up  to  lb 
general-purpose  registers.  These  registers  can  be  used  as  accumulators,  index  registers,  and  or  to 
hold  temporary  results,  file  advantages  ol  the  dedicated  accumulator  approach  are: 

Minimizes  Hardware  With  a general  register  tile,  there  are  more  registers  and  several 
multiplexers  that  arc  not  needed  with  a simple  accumulator  extended 
accumulator  configuration  In  addition,  when  a register  file  is  used,  there 
frequently  will  also  have  t<>  be  additional  working  registers  used  in 
conjunction  with  * lie  register  file  These  working  registers  are  simply  fie 
micro-programmer's  accumulator  and  extended  accumulator  (or  MO  register.). 
It  is  possible  though,  to  implement  tile  general  register  file  as  a part  of  main 
memory,  at  the  expense  ot  decreased  performance  due  to  the  bandwidth 
limitation  ol  memory  lor  both  storage  and  file  operations 

Conserves  instruction  Bit-  It  a general  register  approach  is  used,  bits  must  be 
reserved  in  the  instruction  word  to  specify  which  ol  the  general  registerisi  is 
to  bo  used  In  the  simple  accumulator  extended  accumulator  approach,  there 
are  tew  it  any  bits  used  to  specily  registers. 

Minimized  Interrupt  Save  Restore  The  more  registers  that  exist,  the  longer  tne 
saving  and  restoring  ol  them  takes  when  entering  and  returning  from  an 
interrupt  service  routine  Thus,  the  accumulator  extended  accumulator 
architecture  tends  to  be  taster  and  more  elticient  jt  interrupt  servicing.  One 
point  in  favor  ol  the  virtual  register  file  is  the  ability  to  switch  quickly  to  a 
new  set  ot  “registers"  by  merely  assigning  an  alternate  section  ot  memory  to 
he  tile  new  file. 
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The  disadvantages  ol'  the  simple  accumulator  'extended  accumulator  architecture  are 

Intermediate  Loads  Store  Since  there  is  only  one  accumulator  extended 
accumulator,  intermediate  results  and  temporary  values  must  he  retained  in 
main  memory.  This  causes  a significant  increase  in  the  number  of  load  and 
store  instructions.  The  result  is  an  increase  in  program  si/e  and  execution 
tune. 

1 xtra  Index  Instructions  With  the  simple  accumulator  extenued  accumulator 
configuration,  extra  instructions  are  needed  to  manipulate  the  index 
register! si.  With  the  register  tile  approach.  any  and  ill  instructions  can  he  used 
to  manipulate  the  indexes. 

As  hardware  costs  have  decreased,  the  performance  and  efficiency  ot  the  register  file 
architecture  have  become  most  attractive.  For  the  DP  M processor,  the  two  primary  advantages 
of  a register  file  are. 

Reduced  Memory  For  avionics  application  sol t ware  there  are  typically  4 to  5 times 
as  much  memory  devoted  to  p.ogram  as  data  Thus,  there  can  be  a significant 
savings  in  memory  due  to  eliminating  many  ot  the  instructions  associated  with 
loading  and  storing  temporary  values  and  intermediate  results. 

Simplified  Control  Structure  There  is  no  distinction  between  index  register 
operations  and  other  normal  register  computations.  Thus,  there  are  fewer 
instruction  operations  to  decode  and  execute.  This  causes  the  control 
structure  to  be  smaller  and  simpler 

The  selection  of  a general  register  file  organi/atior.  required  several  additional  design 
decisions.  The  number  ot  registers  in  the  file  and  the  functional  use  of  the  registers  by  th»- 
processor  instruction  set  and  architecture  had  to  be  determined.  The  determination  of  the 
number  of  registers  had  several  factors  to  consider  One  opinion  always  persists:  most 
programmers  and  compiler  writers  feel  there  are  never  enough  registers  and  or  memory  for 
real-time  applications.  Thus  the  difficult  problem  is  one  of  determining  what  the  majority  of  the 
avionic  processing  applications  require.  Because  of  hardware,  instruction  bits  used  per  instruction, 
and  interrupt  save 'restore  considerations,  the  number  of  general  registers  needs  to  be  held  to  a 
usable  convenient  minimum.  Processors  have  been  built  with  4.  8.  and  lb  general  registers.  Most 
contemporary  minicomputers  use  eight  general  registers,  and  avionic  programming  experience 
indicates  that  the  majority  ol  programs  generally  require  4 to  8 accumulators,  indexes,  and 
temporary  storage  locations.  For  these  reasons,  the  DP  M processor  was  specified  with  an 
eight-pencral-register  file,  with  two  of  the  registers  having  special  functions. 

The  next  design  consideration  was  the  handling  of  the  processor  program  counter  (PC). 
The  PC  is  useful  as  a base  to  address  into  the  program  space  both  for  branching  and  fetching 
fixed  data.  It  also  simplifies  the  manipulating  of  the  PC  if  it  is  one  of  the  general  registers.  This 
allows  both  the  PC  to  be  used  as  a base  and  the  use  of  the  full  instruction  set  to  manipulate  it. 
For  example,  an  unconditional  branch  is  a register  (program  counter:  load  and  a branch  relative 
can  be  effected  with  a register-add  instruction. 

A second  file  register  is  designated  for  use  as  a system  or  interrupt  stack  pointer  (see 
Subsection  IV.A.b  for  the  processor  interrupt  system  design).  The  disadvantage  of  including  the 
stack  pointer  in  the  file  is  that  this  uses  up  one  more  of  the  general  registers.  This  is  only  true, 
though,  il  there  is  not  re-entrant  programming.  If  there  is  any  re-entrant  programming,  a stack 
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.itul  .1  pointer  arc  a necessity.  l-or  I lie  DP/M  PL.  it  was  decided  that  the  advantages  of  using  one 
«>i  the  general  registers  for  a stack  pointer  outweighed  the  disadvantages.  Thus,  for  the  1)1*/ M PI*, 
general  register  b is  dedicated  to  being  the  interrupt  stack  pointer.  It  can  also  he  used  as  a run 
time  dynamic  memory  stack  pointer  where  multiple  registers  can  he  saved/restored  automatically 
m available  memory  for  subroutine  and  interrupt  processing  routines. 


Processor  Word  Leimth 


Ihe  basic  word  si/e  for  the  DP/M  I’l-  has  been  set  at  lb  bits.  The  choice  of  a lb-bit 
addressable  word  was  made  in  view  of  the  following  data: 

A large  portion  of  the  avionic  sensor/actuator  input  and  output  signals  have  an 
accuracy  range  from  10  to  12  bits,  with  a relatively  few  signals  whose  digital 
value  exceeds  lb  bits. 

Most  numerical  calculations  with  this  sensor  data  can  be  accomplished  with  lb-bit 
fixed-point  arithmetic,  with  some  instances  requiring  double  precision  (32-bit) 
operations. 

The  use  of  a lb-bit  address  field  within  a l*l;  instruction  format  permits  an 
instruction  address  reach  of  b4K  words  of  memory,  which  is  more  than 
adequate  for  expected  DIVM  applications. 

C haracters  and  short  integers  ( 128  to  +127)  can  be  packed  two  per  lb-bit  word, 
while  double  words  (32  bits)  are  more  than  adequate  for  double  precision 
fixed-point  variables  and  for  software  floating-point  variables. 

An  additional  consideration  in  the  basic  word  size  selection  was  the  number  of  bits  needed 
for  instructions,  this  is  part'  ularly  important  since,  except  for  large  data  base  programs,  there  is 
normally  4 to  5 times  as  much  memory  devoted  to  instruction  storage  as  to  data.  Various  studies 
have  been  made  as  to  the  information  content  of  instructions  for  different  machines  (IBM  7090) 
and  have  shown  that  an  average  number  of  useful  bits  for  instruction  field  is  in  the  15-  to  17-bit 
range.  Thus,  if  the  instruction  set  allows  for  variable-length  operations  (i.e..  short  one  word  and 
long  multiple  word),  then  a lb-bit  word  length  appears  suitable  for  instructions  also.  This  is 
especially  true  it  special  attention  is  given  to  the  most  frequently  executed  instructions.  As  will 
be  seen  later  in  this  section,  this  choice  was  quite  satisfactory  since  75  percent  of  the  DP/M 
executive  code  and  b4  percent  of  the  diagnostic  code  were  able  to  use  single  word  (16-bit 
instructions. 


Two  other  factors  that  were  considered  in  the  selection  of  the  lb-bit  word  length  were  the 
likely  commercial  market  evaluation  of  LSI  memory  and  micro  processor  devices.  Present 
indications  concerning  semiconductor  memory  devices  that  either  currently  exist  or  are  projected 
for  development  indicate  device  partitioning  in  multiples  of  2 or  4 bits  and  a lb-bit  data  word 
could  efficiently  use  either  approach.  The  1972  1974  product  boom  of  4-  and  8-bit  micro- 
processor chip  sets  lends  creditability  to  the  DP/M  concept  of  a low-cost  LSI  commercial 
equivalent  processor  suitable  for  1978  80  avionic  system  applications.  It  is  felt  that  as  LSI 
technologies  improve,  the  lb-bit  “micro  class"  processor  will  be  an  established  computing  device 
within  the  next  2 years  that  will  be  suitable  for  use  in  DP/M-like  systems. 


Data  T>|x*\ 
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I he  1)1’  SI  processor  data  types  available  to  the  programmer  are  hits,  bytes  (characters  and 
short  integers),  and  integers  (single  and  multiple  precision).  Associated  with  each  data  type'  is  a 
..lass  ol  instructions  As  with  most  processors,  the  ingle  precision  integer  processing  is  used  lor 
address  generation 

a Bits 

Bits  are  addressed  by  spec  dying  the  whole  word  that  contains  the  desired  bit(s)  and  then 
speedy i ng  the  bn  or  bits  within  the  word  either  with  a mash  and  using  an  AM)  or  OR 
operation,  or  b\  speeds  mg  the  bit  position  within  the  word  and  using  a SI  T.  ( LI  AR.  or  TFST 
BIT  operation 

b Bytes 

A byte  is  usee*  to  hold  a character  or  a short  integer  (Figure  32 1.  The  I)P/M  byte  is  an 
X-bit  two's  complement  number  which  can  take  on  the  values  I 2X  to  +12'?.  Before  a byte  is 
used  (Figure  33i  it  is  sign  extended  into  a lo-bd  quantity. 
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BYTE  DATA  REPRESENTATION 
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BYTE  USAGE 


Figure  32.  BYTE  Data  Representation 


Figure  33.  BYTE  Usage 


c.  Single  Precision  Sumbers 

Whole  words  jre  used  to  store  addresses  and  single  precision  numbers  (integer  or  fixed 
point i.  A single  precision  number  :s  a lo-bit  two's  complement  number  which  as  an  integer  can 
take  on  the  values  32/,(>X  to  +32.”(i’ 

d Multiple  Precision  Sumbers 

The  format  selc  ted  for  multiple  precision  numbers  (integers  or  fixed  point).  as  shown  in 
Figure  34.  was  derived  in  order  to  simplify  the  software  necessary  to  implement  the  basic 
arithmetic  (unctions  ol  add.  subtract,  multiply,  and  divide.  Thus  the  most  significant  part  will  be 
in  the  first  word  and  the  least  significant  in  the  last  word 

4 Instruction  Complement  Selection 

The  selection  ol  an  instruction  complement  was  based  upon  several  factors.  A review  of 
of  the  contemporary  commercial  and  airborne  minicomputer  instruction  sets  reveals  a 
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Figure  34.  Multiple  Precision  Data  Representation 


striking  similarity  in  the  capabilities  offered  In  the  different  designs.  Hie  approach  on  I)P/M  was 
to  analyze  available  existing  avionic  operational  software,  determine  the  set  of  opeiations  most 
frequently  required  of  real-time  avionic  programs,  and  define  an  instruction  set  that  reflects  these 
requirements.  In  addition,  a concentrated  effort  was  math*  to  simplify  the  programmer's  use  of 
the  instruction  set  and  the  hardware  control  for  decoding  instruction  formats.  The  selection  of 
the  DP  M instruction  formats  stressed  minimization  of  decode  control  and  standardization  of  the 
instruction  operand  derivation  and  execution  cycles  as  much  as  possible. 

I very  DP  M instruction  execution  cycle  can  he  viewed  as  occurring  in  two  phases.  The 
lirsi  phase  is  associated  with  obtaining  an  operand  (from  memory,  a register,  or  within  the 
instruction*,  and  the  second  phase  is  the  use  of  that  operand  in  conjunction  with  a second 
operand  (a  register  or  memory  location)  to  effect  the  desired  operation.  This  process  of  an 
instruction  specifying  two  functions  i the  selection  of  operand  sources  and  the  instruction 
execution  cycle  using  these  operands)  has  two  major  advantages.  The  software  programmer  (or 
compiler)  has  a basic  set  of  instructions  that  can  be  used  with  a variety  of  source/dcstination 
operands.  For  example,  an  add  instruction  can  have  an  implied  destination  register  and  multiple 
operand  sources  (another  register,  contents  of  a memory  address  that  may  be  indexed,  or  an 
immediate  data  value  imbedded  within  the  instruction).  This  flexibility  of  specifying  a wide 
variety  of  operand  types  not  only  adds  power  to  the  use  of  the  instruction  set.  it  also  simplifies 
the  control  logic  required  to  implement  a given  set  of  instructions.  Whenever  an  instruction  is 
fetched  from  memory  and  ready  for  decode,  a predefined  set  of  fields  within  the  instruction  can 
be  decoded  to  derive  the  necessary  operands.  This  operand  derivation  can  be  independent  of  the 
instruction  execution  cycle  and.  hence,  become  common  to  all  operations.  Once  the  operands 
have  been  derived  ami  placed  in  the  appropriate  internal  working  registers,  one  common 
instruction  execution  cycle  can  be  invoked  to  perform  the  operation  using  the  internal  working 
registers  tor  operands. 

This  two-step  approach  of  operand  derivation  and  instruction  execution  is  further 
enhanced  in  the  DIVM  processor  design  try  the  use  of  a minimum  number  of  different  instruction 
formats.  This  emphasis  on  regularity  is  also  intended  to  simplify  instruction  decode  and 
encourage  efficiency  of  instruction  usage  and  execution.  Two  instruction  formats  have  been 
defined  for  the  DP/M. 

file  standard  instruction  formal  which  provides  both  short  (one-word)  and  long 
(two-word)  instructions 

The  extended  short  instruction  format  which  provides  a limited  number  of  short 
instructions  for  high  frequency/efficiency  operations. 

The  standard  format  provides  a full  complement  of  instructions  with  the  desired  types  of 
operands  determining  the  length  of  the  instruction  word  generated.  Operands  found  in  registers 
require  short  instructions  while  operands  requiring  full  memory  addresses  or  16-bit  or  constant 
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data  require  long  instructions  The  extended  short  lorm;it  provides  small  constant  (immediate) 
values  to  he  used  tor  either  d*ta  and  or  displacements  in  oik  short  instruction  to  minimize 
program  memory  and  execution  time  tor  high-frequency  operations. 

a.  Standard  Format  Instructions 

Hie  standard  tormat  instructions  are  intended  to  provide  a lull  range  ol  operations  suitable 
tor  real-time  avionic  system  applications  like  1)1*  M.  A lull  set  ol  instruction  operations  and 
operand  modifications  were  considered  tor  incorporation  into  the  1)1’  M processor  specification. 
The  operand  t>|vs  and  addressing  modes  initially  identified  as  candidates  lor  l)P  V.  were 

Constant  (or  immediate)  data  that  is  imbedded  as  part  o|  the  instruction  lormal 

Register-to-register  where  both  operands  are  located  within  registers  m the  I lie 

Direct  where  the  operand  is  the  contents  ol  a memory  address  in  the  instruction 

Direct  indexed  where  the  operand  is  the  contents  ol  a memory  adi’vss  whose  value 
is  the  stun  ol  a held  in  the  instruction  and  an  index  register 

Indirect  where  the  addiess  held  in  the  instruction  is  a memory  location  whose 
contents  are  the  memory  address  ol  the  desired  quantity 

Indirect  Indexed  is  identical  to  Indirect  except  indexing  is  applied 

Register  Indirect  (Rli  where  the  memory  address  ol  the  desired  operand  is  contained 
in  one  ot  the  tile  registers 

Register  Indirect  with  Autoincreinentmg  (RIA)  is  identical  to  Register  Indirect 
except  the  register  containing  the  memory  address  is  incremented  auto- 
matically alter  the  operand  is  fetched. 

The  latter  two  lornis  ( R1  and  RIA)  ol  indirect  addressing  use  the  contents  ol  a register  as  an 
address  lor  the  data  These  two  torms  ol  addressing  allow  elhcient  data  accessing  within 
processing  loops,  and  the  RIA  form  is  particularly  etticient  lor  stepping  sequentially  through 
tables  Register  Indirect  is  used  lor  arbitrarily  generated  addresses  By  examining  several  samples 
ol  avionic  applications  code,  it  was  observed  that  (ll  there  was  frequent  use  ol  direct  indexed 
instruction  (the  fourth  item  above)  with  an  address  displacement  held  ol  zero  lie  . the  address 
was  contained  in  the  register),  and  1 2 ) table  access  within  loops  was  usually  sequential.  These 
observations  influenced  m part  the  selection  ol  the  following  DP  M processor  addressing  operand 
modes 

Register-to-Register  l RK> 

Register  Indirect  iRIi 

Register  Indirect  with  Automcrcmeni  (RIM 

( onstant  or  Immediate  Data  (<  l 

Direct  (Di 

Direct  Indexed  ( D\i 

The  implementation  ol  these  six  desirable  addressing  modes  was  accomplished  in  the  following 
manner.  The  RR.  Rl.  and  RIA  modes  were  given  unique  hardware  description  codes  for  the 
operand  derivation  cycle,  as  was  the  Direct  memory  address  modification.  The  remaining  two 
addressing  modes.  Direct  Indexed  and  Constant,  were  implemented  without  unique  operand 
modification  descriptors  The  use  ot  one  ol  the  register  file  members  for  a default  condition  of 
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no  indexing  allows  the  Direct  mod ilk.it ion  to  he  linn-indexed  < I > t or  indexed  tl)\t.  depending 
upon  the  value  ot  the  index  register  A standard  convention  oMiiiiiunk  usi.il  is  that  register  zero 
( Rl ) > is  non-mde\.il'le.  and  that  a non-zero  index  register  implies  automatic  indexing  lie.  I).\  is 
uctuallv  a I)  modilkation  with  a nou-zeio  index  legisterl  I Ills  convention  is  the  approach  used 
lor  the  1)1*  M standard  lomia!  dned  dnect  indexed  instructions  as  well  as  the  memorv 
input  output  instructions  I lie  constant  modilkation  provides  lohiis  o|  immediate  data  tor  use 
In  the  mstriktion  I his  modilkation  is  easilx  au omplished  In  using  tl.e  register  tile  member 
containing  the  program  counter  I PC  i tor  the  RlA  operand  register  tie.  the  IX  points  to  the 
next  lii-hit  word  and  is  automatic.ilh  incremented  to  the  next  instruction  attei  the  constant 
data  has  been  teteliedi 
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This  .ipproji.li  lo  tlur  ( and  l)\  operand  specification  means  tli.it  mils  a two-hit 
modifk .ition  designation  is  required  to  deline  the  sis  types  ot  jddiess  iiuhIsI it. jtitm.  Hire'-  ^its  to 
speedy  the  index  or  operand  register  and  possibly  an  additional  word  lor  addicss  or  immediate 
data 


The  design  speeilied  lor  the  processor  uses  separate  register  designations  (R~  and  KO)  tor 
the  PC  and  non-indexing  functions.  respectively  This  convention  is  maintained  throughout  the 
design  specification  There  is.  however,  an  alternative  that  i>  worth  soii'iderim:  The  use  o!  the 
PC  tor  indexing  purposes  permits  program  counter  relative  addressing,  however,  tne  merits  ol  this 
inoile  are  unclear  with  the  use  ol  ROM  i write  prevention!  memories  Hit  use  ot  the  PC  to 
distinguish  non-indexing  sou  Id  essentially  Iree  up  one  more  genera*  register  tor  use  as  an 
index  base  register  tor  operand  modifications 

The  next  part  ol  the  instruction  execution  design  to  consider  is  ihe  operation  phase  Three 
hits  are  required  to  speedy  the  source  destination  register  during  .ie  •'••fat ion  I wo  hits  will  be 
used  as  part  ot  the  extended  short  !•  -mat  ileMgnatioi.  I Ins  assigns  nls  In  percent  >t  tile 
instruction  bits  to  allow  40  percent  to  ^ percent  ol  tl  .■  instructions  to  use  the  one-word 
extended  short  tornut  rather  than  a two-word  standard  0 iniat  Hit's  leaves  <>  bits  to  specify  one 
of  b4  possible  standard  tornut  operations  These  t>  bit'  permit  the  spec  it  ic.it  ion  ot  M unique 
operations,  which  should  be  more  than  enough  tor  the  DP  Si  processor  Xctuallv  only  .TO  basic 
standard  tornut  instructions  have  been  del  tiled  tor  the  processor 

Figure  35  shows  the  standard  instruction  tornut  and  fable  ' lists  the  standard  operations 
selected  tor  the  DP  M instruction  set 

In  figure  35  the  six  fields  ol  the  standard  it  -t  ruction  tornut  domed  tor  the  DP  M PF 
are 

\ Two-bit  held  ol  all  zeros  tor  the  standard  tornut.  used  to  dillerentute  between 
standard  and  extended  short  tornut  instructions 

C Six-bit  command  held,  used  to  speeds  the  desired  operation  such  as  load,  store, 
add.  subtract,  etc 

V Two-bit  operand  modification  held,  used  in  eontunetion  with  the  T held  and 
possibly  jn  A held  to  determine  the  operand  (Derived  Operand  (DO)  or 
Derived  Address  il)\)|  to  be  used  during  the  operations  specified  by  tile  C 
held  figure  35  shows  the  various  DOs  and  IMs  as  a I unction  ot  the  M.  T. 
and  A fields 

T Three-bit  held  which  specifies  the  register  or  index  hjse  to  be  used  as  part  ol 
the  operand  Note  that  H register  0 or  ' is  speeilied.  special  actions  occur  as 
described  above' 

R Three-bit  held  which  spedhes  the  accumulator  to  be  used  during  the  operation 
or  the  branch  condition  tor  a conditional  brand). 

A The  next  instruction  word  in  the  instruction  stream  which  it  used  contains  j 
word  ot  constant  data  or  an  address. 

Note  tnat  the  f and  R tick!  may  be  used  to  specify  either  a single  register  or  a register  pair 
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Figure  .15.  Standard  Instruction  Format 


The  30  standard  format  instructions  specified  for  the  DP  M pkkcwh  r-.-prevnt  a 
minimum  but  adequate  set  of  operations  lor  expected  real-time  avionic  environments  Ihe 
capabilities  of  this  instruction  set  include: 

Memory  bit  field  manipulation  under  a mask  operation 

Data  movement  instructions  like  Push  and  Move  and  \i.umicrement  tor  elt.-cient  list 
ard  table  processing 

Register  file  save  restore  operations  for  interrupt  processing  and  subroutine 
processing 

A full  complement  of  signed  lft-bit  ar  ' imetic  operations 
A full  complement  of  16-bit  logical  operations 

A full  complement  of  bit  manipulation  operations  that  provide  an  uninterruptible 
memory  read/modify' wnte  capability 

Single-  and  double-length  shifts  including  arithmetic,  logical  and  circular  types 
whose  shift  counts  are  specified  by  the  derived  operand  of  the  instruction 

A conditional  branch/transfer  capability  with  lull  MK  address  reach 

Basic  interrupt  sta-us  save  restore  instructions 

Input/output  instructions  where  the  data  command  information  to  be  processed  is 
found  in  the  register  file. 

The  standard  set  of  hardware  instructions  shown  in  Table  ' can  be  expanded  by  adding  new 
operations  (and  more  hardware  > to  use  one  of  the  34  unused  operation  codes  or  by  using  an 
invalid  “op-code”  detect  interrupt  to  simulate  desired  instructions  with  interpretive  software 
routines. 

b.  Extended  Short  Fornat  Instructions 

As  mentioned  earlier,  a frequent  use  was  identified  for  a few  instructions  that  only  need  a 
short  (8-bit)  data  ^ displacement  field.  The  DP/M  PE  extended  short  instruction  formats  are 
shown  in  Fim\c  36.  The  usage  of  the  DP/M  PE  extended  short  format  instruction  set  is  shown  in 
Table  8 ihe  extended  short  format  duplicates  the  most  common  standard  format  operations  but 
.n  a short  format.  The  inclusion  of  this  short  format  is  based  on  the  observation  that  a few 
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Figure  (6.  Extended  Short  Instruction  Formats 


and  one  for  the  subroutine  entry  address),  once  the  linkage  address  is  defined,  all  other 
subroutine  calls  require  only  a single  word  instruction. 

c.  Input /Output  Instructions 

The  DP/M  I/O  operations  use  the  standard  format  for  register  I/O  and  a variant  of  the 
extended  short  format  for  memory  I/O.  In  both  cases,  there  is  an  8-bit  I/O  Command  Address 
Word  fCAW),  This,  in  conjunction  with  the  direction  of  data  flow  (in  versus  out),  is  used  to 
specify  which  external  device(s)  are  to  respond  and  what  action  they  are  tc  take.  In  some  eases, 
there  is  no  data  to  be  processed,  but  simply  a commanc  specified  by  the  particular  CAW.  Thus, 
the  8-bit  CAW  and  direction  of  I/O  can  access  512  devices  (256  in  and  256  out)  or  specify  512 
operations  or  any  combination.  Normally,  a CAW  is  directed  at  a particular  device  and  the  data 
word  transmitted  is  the  actual  device  command.  This  allows  each  of  256  devices  to  be  given  as 
many  as  64K  unique  commands. 

The  register  I/O  instruction  uses  the  derived  operand  as  the  CAW  and  inputs  or  outputs 
the  data  to  or  from  the  register  specified  by  the  R-field.  The  memory  I/O  instructions  use  a 
modified  extended  short  format  instruction  (32-bits)  (see  Figure  37).  The  8-bit  immediate  1-field 
is  the  CAW  and  the  memory  location  is  specified  by  the  second  half  (16  bits)  of  the  instruction. 
If  the  R-field  is  other  than  register  0,  indexing  takes  place.  To  keep  from  “hanging*’  the 
processor  waiting  for  an  external  device  to  acknowledge  an  I/O  operation,  the  I/O  control  chip 
performs  any  required  timeout  function  necessary  to  allow  a device  data  receipt/acknowledge 
sequence  to  be  generated.  If  the  timeout  on  I/O  occurs,  the  processor-condition  code  will  be  set 
to  reflect  the  failure  of  the  I/O  operation.  Further,  if  the  I/O  timeout  interrupt  is  enabled 
(device  error  mask),  an  I/O  interrupt  trap  will  also  occur.  “ 

d.  Summary  of  Processor  Instruction  Set  Characteristics 

To  reduce  the  complexity  of  the  instruction  decode,  the  number  of  formats  has  been 
limited  and  the  instruction  cycle  standardized.  The  majority  of  the  instructions  are  in  the 
standard  format  that  allows  for  a large  number  of  operations  (64)  and  a full  range  of  addressing 
modes  (6).  Added  to  this  powerful  set  of  instructions  is  a small  set  of  extended  short  format 
instructions.  These  short  format  instructions  implement  the  more  frequently  executed 
instructions.  These  short  format  instructions  can  save  25  to  35  percent  of  the  space  and 
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Figure  38.  DP/M  Processor  Instruction  Formats 


execution  time  of  a program.  Figure  .>6  shows  how  the  fields  of  the  standard  and  extended  short 
format  instructions  are  aligned.  This  reduces  the  amount  of  hardware  logic  required  to 
implement  instruction  decoding.  Tables  7 and  8 list  the  processor  instruction  set.  Any  of  the 
invalid  instructions  can  be  used  to  implement  a trap  and  emulate  operation.  This  would  allow 
the  inclusion  of  extra  operators  through  the  inclusion  of  the  appropriate  software. 

5.  Instruction  Usage  Observation 

Scvcrui  different  programs  and  sample  cases  were  studied  during  the  course  of  the  DP/M 
processor  design  specification.  The  first  such  operational  software  module  was  a 12,000 
instruction  Electronic  Warfare  ( HW)  program.  This  program  was  written  for  an  avionic  digital 
computer  which  had  an  instruction  set  similar  to  the  DP/M  standard  format  instructions.  The 
next  programs  examined  were  the  DP/M  executive  and  one  version  of  the  DP/M  instruction 
diagnostic  program.  The  results  from  these  three  programs  are  summarized  in  Table  9.  The  use  of 
register  indirect  autoincrcmcm  for  manipulating  data  structures  is  shown  and  the  applying  of  the 
DP/M  instruction  set  to  a simple  FORTRAN  subroutine  linkage  with  "pass  by  reference" 
variables  is  presented. 

a,  Extended  Short  Instruction  Format  Usage  Analysis 

The  sample  static  instruction  usage  shown  in  Table  9 is  based  on  postulating  the  effect  of 
the  extended  short  instruction  format  on  the  aforementioned  EW  program  wntten  for  a digital 
computer  whose  instruction  set  was  similar  to  the  DP/M  standard  instruction  format.  The 
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:mal\sis  was  performed  by  running  Hie  operational  flight  program  source  code  through  a program 
whicli  counted  the  ruimher  ot  times  that  each  operation/modification  combination  occurred.  The 
extended  short  lormat  instruction  usage  was  then  estimated  by  counting  the  standard  format 
operation/moditication  pair  that  corresponded  to  the  extended  short  instructions.  Then,  the 
traction  ol  that  usage  that  could  have  used  a short  (8-hit)  constant  value  rather  than  the  long 
i In  bill  constant  value  was  estimated.  This  instruction  usage  data  corresponds  to  the  static  case 
only  Clearly,  the  highest  usage  was  for  short  relative  branching,  both  conditional  and 
unconditional,  which  accounted  for  almost  20  percent  of  the  instructions  used.  The  increment 
and  branch  if  negative  instruction  has  been  included  because  of  its  relatively  high  dynamic  usage 
for  loop  processing.  Its  function  is  to  increment  the  register  specified  and  to  branch  if  the 
register  is  negative.  The  subroutine  call  instruction  saves  the  current  program  counter  (PC)  in  the 
register  specified  and  branches  indirectly  through  one  of  the  first  256  memory  locations.  This 
instruction  makes  subroutine  linkage  efficient  and  supports  modular  programming.  There  is  also  a 
high  usage  of  short  immediate  data  for  count  and  address  processing.  Count  processing  records 
number  ol  events,  loops,  etc.  fit  us.  the  most  frequently  used  instructions  for  short  immediate 
data  ( 128  to  +12?)  are  load.  add.  and  compare.  These  three  operations  amount  to  more  than 
10  percent  of  the  static  instruction  usage.  The  next  most  frequently  occurring*  class  of 
instructions  is  loads  and  stores  that  are  PC  or  base-relative  with  an  address  displacement  from  the 
base  of  128  to  +127.  Tins  sample  case  shows  a 30-percent  savings  in  memory  space  due  to 
these  eight  extended  short  instructions  formats. 

Portions  of  the  code  written  for  the  DP/M  processor  instruction  diagnostic  and  executive 
were  also  analyzed.  The  results  were  somewhat  better  overall  than  that  estimated  trom  the  HW 
program.  This  is  probably  due  in  part  to  a conscientious  effort  to  use  the  extended  short 
instructions  since  they  were  available.  Both  the  executive  and  the  version  1.0  instruction 
diagnostics  showed  a 30-percent  program  memory  savings  by  using  the  16-bit  extended  short 
instructions  rather  than  the  32  bit  standard  format  instructions  (e.g..  BCS  - 16  bit  versus  BC  - 32 
bin.  The  dynamic  (simulation)  data  was  also  available  for  the  version  1.0  instruction  diagnostics. 
The  static  usage  was  very  close  to  the  dynamic  usage  except  for  the  IBNS  which  was  used  for 
loop  closing.  The  extended  short  and  the  corresponding  standard  format  instructions  have 
execution  times  limited  by  the  memory  cycle  speed. 

Thus,  there  is  nearly  a 2 to  ! savings  in  execution  time 
of  an  extended  short  instruction  over  its  standard  format 
equivalent,  in  the  ease  of  the  version  1.0  diagnostics,  a 
25-percent  savings  in  execution  time  resulted  from  using 
the  extended  short  instructions. 

h tiffed  of  Instructions  Sot  Included 

< I » Double  Precision 

The  I AV  program  had  a small  usage  of  double 
precision  operations,  which  are  shown  in  Table  10. 

Clearly,  the  3-pcrcenl  double  load/store  operations 
will  not  add  significantly  to  either  the  program  spaee 
md  or  execution  times  since  t hey  can  easily  be 
accomplished  by  simply  using  two  single  load/store 
operations.  There  were  no  double  arithmetic  operations 
exo'pi  for  the  0.4-percent  double  adds.  Thus,  even  if 


TABLE  10.  DOUBLE  PRECISION 
OPERATION  USAGE 

Percent 

Load 


Constant 

0.6 

Direct 

1.0 

Direct  indexed 

0.1 

Total 

1.7 

Direct 

0.0 

Direct  Indexed 

0.4 

Total 

1.3 

Register 

0.2 

Constant 

0.1 

Direct 

0.1 

Total 

0.4 
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they  took  10  times  as  long  to  simulate,  they  still  would  not  greatly  affect  program  execution 
time. 

(2)  Bytes 

The  FW  program,  as  well  as  several  other  much  larger  avionic  programs  which  were 
examined,  did  extensive  display  manipulation,  but  in  none  of  the  cases  was  the  lack  of  character 
(byte)  manipulation  considered  a serious  problem.  Fven  though  there  was  extensive  display 
processing,  it  did  not  constitute  a large  processing  load.  Thus,  there  was  plenty  of  time  to 
manipulate  character  data  by  using  shifting  and  masking  (AND)  operations. 

(3)  Floating  Point 

The  EW  problem  and  the  several  others  examined  could  have  used  floating-point  data  and 
operations.  The  increased  hardware  cost  and  loss  of  processor  performance,  though,  could  not  be 
justified  and  the  next  generation  16-bit  commercial  microprocessor  is  also  not  likely  to  have 
these  operations. 

Based  on  this  information,  it  is  difficult  to  justify  the  additional  hardware  to  implement 
these  added  operations.  If  some  operations  were  to  be  added,  the  following  ranking  seems 
appropriate: 

Double  precision  adu 
Double  precision  load  store 
Character  < byte  t manipulation 

c.  Data  Structures  Using  Register  Indirect  Autoincrement 

The  register  indirect  with  autoincrement  operand  modification,  in  addition  to  being  used 
for  constant  data  and  scanning  through  tables,  can  be  used  for  more  sophisticated  data  structures 
such  as  queues  and  stacks.  A queue  can  be  implemented  by  u-mg  two  registers  as  pointers  to  the 
queue.  One  pointer  is  for  the  input  and  the  other  is  for  the  output.  The  pointers  are  then 
scanned  through  the  queue  by  using  the  register  indirect  with  autoincrement  modification  on  the 
instructions  that  access  the  queue.  Similarly,  a stack  can  be  defined  using  one  register  whose 
contents  serve  as  a pointer  to  the  top  of  the  stack.  One  way  of  defining  a stack  (last  in-first  out 
list)  is  to  define  the  top  to  have  a smaller  address  than  the  bottom  (Figure  3‘D.  This  allows  the 
use  of  register  indirect  with  autoincrement  to  remove  (POP)  data  off  of  the  top  of  the  stack. 
With  this  definition,  all  that  is  required  is  a single  “push”  instruction  to  store  data  into  a stack. 
The  push  instruction  is  used  to  store  data  into  a stack  just  like  a store  instruction  would  be  used 
for  other  types  of  data  structures.  This  type  of  stack  structure  is  used  for  interrupts  where 
register  6 serves  as  the  interrupt  stack  pointer.  This  interrupt  stack  can  also  be  used  for  register 
file  savings  and  restoring  for  interrupts  and  subroutines  via  the  push  and  pop  multiple 
instructions. 

d.  Sample  Subroutine  Linkage 

While  at  first  glance,  it  may  have  seemed  that,  due  to  the  lack  of  the  indirect  addressing, 
there  would  be  significant  inefficiencies  in  subroutine  parameter  passing.  Hus  is  not  true  with 
the  DP/M  PI.  instruction  set.  An  instruction  normally  would  take  two  words  if  indirect 


addressing  were  available  (one  word  o!  operation,  addressing  mode  and  register  and  one  word  of 
address- displacement).  Without  indirect  addressing,  though,  it  can  be  done  on  the  DP/M  by  using 
an  extended  short  format  load  direct  short  instruction  to  get  first  the  address  and  then  a 
standard  format  instruction  using  register  indirect.  This  sequence  uses  the  same  number  of 
memory  locations  and  operates  at  about  the  same  speed  as  would  the  two-word  indirect 
addressing  instruction. 

As  an  example,  consider  the  following  FORTRAN  “pass-by-reference”  operation 
(Figure 40)  where  the  addresses  of  the  calling  parameters  are  placed  in  the  instruction  stream 
following  the  branch  and  link  to  subroutine.  Assume  the  following  register  usage: 

Register 

0 to  3 

4 

5 

6 

7 

And  where. 

Standard  Format 
L-  Load 
ST-Store 
A-Add 
R-Register  Modification 
RI-Register  Indirect  Modification 
Extended  Short  Format 

LDS-Load  Direct  Short 
ACS-Add  Constant  Short 
BILR  -Branch  Indirect  and  Link  Register 
Assembler  Directive 

DC- Declare  Constant  (one  word  of  address  or  label). 

This  code  sequence  takes  the  same  program  space  and  executes  in  nearly  the  same  time  as 
the  more  conventional  type  of  indirect  addressing  were  used.  There  was  no  attempt  to  optimize 
the  above  code  by  using  autoincrementing  to  step  through  the  parameters  or  other  such 
techniques.  The  above  code  is  representative  of  that  which  a simple  compiler  would  generate.  It 
does,  however,  show  the  flexibility  of  the  DP/M  instruction  set  and  its  ability  to  support 
higher-order  language-linking  convention*  It  should  also  be  noted  that,  when  passing  an  array 
address  by  reference,  both  pre-  and  post-indexing  are  required.  This  can  be  complicated  with 
conventional  instruction  sets  but  it  can  be  handled  easily  with  the  DP/M  baseline  PE  instruction 
set. 


Use 

Computation 
indirect  Addressing 
Return  Link 
Interrupt  Stack  Pointer 
Program  Counter 


From  the  existing  and  new  programs  that  were  examined,  the  DP/M  instruction  set  seems 
to  be  very  flexible  and  efficient.  It  would  be  interesting  to  see  if  the  previous  programs,  such  as 
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T t?  , 10W  m ?mc  SOrt  of  improvement  that  the  I)P/M  executive  and  diagnostic 

fnrmd,‘  T?  7°“  ‘ . lhc,  W™"1™  find  more  ways  of  making  use  of  the  extended 
had  hew  availaWe  reglst<r‘inU,rcct/registcr*inilircct  “utoincrcmcnt  modifications  if  these  options 

6.  Processor  Interrupt  Structure 

This  subsection  covers  the  interrupt  structure  us  viewed  by  the  processor.  An  attempt  has 

LnabiliJvl  n ZZTr, thC  ,reqU'rCd  llUaW  in  ,hc  lessor  while  providing  as  much  system 
P it/  as  possible.  The  interrupt  structure  can  be  broken  down  into  two  functional  purts.  The 

first  is  the  controlling  or  enabling  ol  individual  interrupts  and  the  other  is  the  switching  of  the 
machine  state  (context  switching).  This  interrupt  control  can  be  accomplished  by  having  one  or 
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FORTRAN 


100 

200 


SUBROUTINE  TWCSUM  i IM  1 . I N2 , IOUT > 

IOUT  - INI  - IN2 

END 

MAIN 

• 

CALL  TWOSUM  ( IA,  IB,  1C'. 

END 


DP  M MACHINE  CODE 


100 


200 


•SUBROUTINE  TWOSUM  MN  1 , IN2,  IOUT) 


•IOUT  ‘ 

- INI 

- IN2 

LDS 

R4, 

R5, 0 

GET  ADDRESS  1ST  PARAMETER 

L.RI 

R0, 

R4 

LOAD  1ST  PARAMETER 

LDS 

R4 . 

R5,  1 

GET  ADDRESS  2ND  PARAMETER 

A.RI 

RO, 

R^ 

ADD  2ND  PARAMETER 

LDS 

R4, 

R 5,  2 

GET  ADDRESS  3RD  PARAMETER 

ST.RI 

R0. 

R4 

STORE  3RD  PARAMETER 

ACS 

R5. 

*3 

STEP  OVER  PARAMETERS 

L.R 

R7, 

R5 

RETURN 

•END 

•MAIN 


•CALL  TWOSUM 
BILR  R 5 . TWOSUM 
DC  A 
DC  B 
DC  C 


CALL  TWOSUM 

ADDRESSES  OF  PARAMETERS 
RETURN  POINT 


'END 


Figure  40  Sample  FORTRAN  Subroutine  Linkage 


more  levels  of  interrupt  masks.  For  example,  there  can  be  a primary  interrupt  mask  with  each 
bit  in  it  controlling  whether  or  not  any  interrupt  will  be  allowed  from  a particular  level  of 
interrupts  'n  this  case,  there  could  be  multiple  secondary-level  masks  that  enable  individual 
interrupts,  v hich  are  at  the  same  level.  The  second  functional  part  of  an  interrupt  sequence  is 
the  initiating  of  the  desired  action  based  on  which  interrupt  occurred.  This  can  be  done  with 
either  hardwaie  or  software.  When  it  is  done  with  hardware,  usually  an  interrupt  trap  vector  is 
used.  The  interrupt  trap  vector  memory  locations  contain  the  address  of  the  interrupt  service 
routine  and  the  new  processor  status  word(s).  The  hardware  then  saves  the  old  program  counter 
and  status  word(s)  and  loads  the  new  ones  from  the  interrupt  trap  vector.  An  alternative 
implementation  is  to  have  the  interrupt  trap  lc cations  contain  an  instruction  which  is  executed 
out  of  sequence.  The  latter  approach  is  much  more  efficient  in  the  case  where  the  interrupt 
routine  is  only  one  instruction  long  (e.g.,  counting)  but  is  less  efficient  for  entering  longer 
routines.  If  there  is  not  a hardware  trap  vector,  the  same  type  of  action  can  be  implemented  in 
software. 

a.  Interrupt  Control  Structure 

The  first  item  to  be  de  led  concerning  the  interrupt  control  structure  is  whether  it  should 
be  single-level  or  multiple-level  and.  if  multiple-level,  how  many  levels  should  be  provided.  The 
single  level  requires  the  least  hardware  but  at  the  expense  of  slow  interrupt  response  and 
increased  proce'sor  software.  By  carefully  determining  which  functions  must  be  provided  by  the 
processor  and  which  can  be  external  to  the  processor,  it  was  concluded  that  the  hardware 
required  in  the  processor  could  be  quite  minimal.  Thus,  by  proi  'ing  minimal  hardware  in  the 
processor,  the  interrupt  structuic  can  be  as  sophisticated  or  simplistic  as  system  requirements 
dictate  and  or  external  hardware  orovides. 

Thus,  for  simplicity  and  flexibility,  the  interrupt  structure  of  the  DP/M  PE  is  distributed 
between  the  processor.  I/O,  and  BIU.  Each  portion  controls  that  part  of  the  interrupt  structure 
that  is  appropriate  to  it.  As  such,  the  processor  controls  its  own  internal  interrupts  (overflow, 
invalid  op-code,  I/O,  and  memory  timeout!  and  all  interrupt  masks.  The  processor  has  a stains 
word  (Figure  41)  which  contains  a two-bit  condition-code  register,  an  overflow  indicator  and 
interrupt  mask,  a device-error  interrupt  mask,  a memory-error  interrupt  mask,  and  10  bits  of 
mask  for  interrupts  external  to  the  processor  (i.e..  the  I/O  and  BIU).  These  latter  10  bits  are 
evternai  to  the  processor  chip  and  reside  physically  on  the  I/O  and/or  BIU  chips,  and  are 
assessed  by  the  processor  performing  an  I/O  operation  with  a CAW  of  00  (Hex)  as  a part  of  any 
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EXTERNAL  INTERRUPT  MASK  (IM) 

-♦MEMORY  ERROR  MASK  (MEM) 

-♦DEVICE  ERROR  MASK  (DEM) 

-♦OVERFLOW  INTERRUPT  MASK  BIT  (OIM) 
-►OVERFLOW  FLAG  BIT  (OF) 

-♦CONDITION  CODE  REGISTER  (CCR)  - SIGN  AND  ZERO 


Figure  41.  Status  Word  Format 
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status  \vnnl  read/wrltc  instruction.  I Inis.  whatever  a statu*  word  read  or  write  instnution  is 
executed.  the  processor  directly  iiceesses  its  own  t>  bits.  uml  accesses  (to  the  processor)  the 
remaining  external  10  hits  hy  simulating  an  I/O  instruction  with  a CAW  of  00  (Ilex).  These  10 
external  interrupt  mask  hits  can  he  used  to  directly  control  Interrupts  or  levels  ot  Interrupts.  In 
the  case  of  an  interrupt  level,  the  status  word  hit  would  enuhle  or  dlsuhle  a whole  Interrupt  level. 
Then  there  would  he  additional  external  mask  worths)  which  would  he  used  to  control  the 
enabling  and/or  disabling  or  individual  interrupts.  These  additional  external  mask  word(s)  would 
be  accessed  viu  other  I/O  instructions. 

It.  Interrupt  Context  Swtichlnu 

As  with  the  interrupt  mask,  the  interrupi-initiuted  response  is  distributed  between  the 
processor.  I/O.  and  B1U.  The  piocesstu  supports  Internully  and  externally  vectored  Interrupts. 
Thus,  when  an  interrupt  occurs,  the  curient  program  counter  and  status  word  arc  suvcil.  and  the 
new  values  are  touded  Irom  a pair  ol  memory  trap  locations  unlt|uc  to  the  particular  interrupt. 
In  the  case  of  internally  generated  interrupts,  (he  processor  determines  titc  trap  locations.  hi.  all 
external  (I'O  and  MU)  interrupts,  the  trap  locations  urc  specified  hy  the  Interrupting  unit  in 
response  to  the  Interrupt  acknowledge. 

As  mentioned  above  In  servicing  an  interrupt,  the  current  program  counter  and  status  word 
must  he  saved  so  that  the  Interrupted  program  may  he  resumed,  The  question  then  Is  where 
should  these  words  he  saved.  There  arc  several  candidate  approaches  includii.g: 

Dedicated  Registers  In  this  case  there  Is  u dedicated  set  of  registers  that  hold  the 
previous  program  counter  and  status  word.  This  works  well  for  the  first 
Interrupt,  but  handling  of  subsequent  interrupts  requires  saving  these  registers 
somewhere  else.  Thus,  the  basic  problem  Inis  not  been  solved,  only  forestalled. 
Another  disadvantage  is  the  additional  registers  and  hurdwure  required  in  the 
processor. 

Dedicated  Hardware  Stack  in  this  case,  the  IV  and  status  word  arc  pushed  into  a 
hardware  stack.  This  solves  the  problem  of  what  to  do  with  subsequent 
interrupts  but  at  the  expense  of  even  more  hardware.  It  ulso  has  a limited 
nesting  of  interrupts,  limited  hy  the  si/e  of  the  hardware  stuck. 

Single  Dedicated  Memory  Location  In  this  case,  the  PC  and  status  word  are  saved 
into  a fixed  pair  of  memory  locutions.  This  bus  the  advantage  of  minimum 
hurdwure.  It  still  suffers  as  “a"  above;  namely,  what  to  do  with  subsequent 
interrupts. 

Scpurutc  Dedicated  Memory  locations  in  this  cusc.  the  PC  and  status  word  are 
suved  into  different  pairs  of  memory  locutions  for  cadi  interrupt  level.  This 
requires  little  hurdwure  and  solves  the  cusc  of  multiple  interrupts  us  long  us  no 
more  than  one  interrupt  is  allowed  per  level.  This  docs  present  a serious 
problem,  though,  when  the  memory  si/e  und  type  is  variable  (ROMs  und 
RAMs).  That  is.  (lie  trap  vector  wunts  to  be  in  ROM  uml  the  suve  vector  must 
he  in  RAM. 

Memory  Stack  In  Hus  cusc.  the  PC’  und  stutus  word  ure  pushed  into  a stack  pointed 
to  hy  a hurilwurc  register.  This  allows  virtually  unlimited  nesting  of  interrupts 
from  u different  or  the  same  interrupt  level,  h also  allows  arbitrary  separation 
between  the  interrupt  trap  vector  and  the  save  urea. 
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INTERRUPT  STACK 


Figure  42.  Restoring  of  Progmm  Counter  and  Status  Word 


This  latter  approach  is  the  one  chosen  for  the  DP/M  processor  because  it  appears  to  offer 
the  greatest  flexibility  with  a minimum  of  extra  hardware.  Figure  42  shows  the  status  word  (SW) 
and  the  program  counter  being  stacked  (PUSHed)  onto  the  interrupt  stack  using  the  interrupt 
stack  pointer  (ISP).  Figure  43  shows  the  SW  and  PC  being  restored  (POPed)  from  the  interrupt 
stack.  The  next  question  is  whether  the  stack  pointer  register  should  be  an  additional  register  or 
one  of  the  general  registers  in  the  file.  The  advantages  of  using  one  of  the  general  registers  are: 

Less  hardware 

No  extra  instructions  needed 

Can  be  used  as  part  of  a general  memory  management  scheme  for  re-entrant  coding. 

As  previously  noted  in  the  register  discussion,  the  disadvantage  is  tha*  this  approach  uses 
an  additional  general  register.  But,  if  there  is  any  re-entrant  programming,  a stack  and  a stack 
pointer  are  required.  Thus,  for  the  DP/M  PE,  general  register  6 is  dedicated  to  being  the  interrupt 
stack  pointer. 

In  summary,  the  DP/M  processor  supports  multiple-level  interrupt  masking,  vectored 
interrupt  trapping,  and  a memory  stack  for  saving  the  machine  state  (PC  and  status  word). 

7.  Processor  Initialization 

The  initialization  of  the  DP/M  PE  consists  of  setting  the  program  counter  of  the  processor 
to  the  beginning  of  the  initialization  routine  that  is  usually  a bootstrap  loader  program  in  read 
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Figure  43.  Restoring  of  Program  Counter  and  Status  Word 


only  memory  (ROM)  which  then  loads  a program  module.  This  program  module  can  be  the  total 
program  or  another  more  powerful  loader  which  then  loads  the  desired  program(s). 

The  initialization  start  address  is  sent  to  the  processor  over  the  internal  processor  bus 
(Subsection  IV.D)  similar  to  the  way  that  the  interrupt  trap  address  is  sent  to  the  processor. 
That  is,  the  address  is  placed  on  the  internal  data  lines  and  the  proper  control  lines  are  activated. 
This  signal  forces  the  program  counter  to  be  loaded  from  the  I-BUS  data  lines  and  instruction 
fetch  to  be  initiated.  Therefore,  it  is  the  responsiblity  of  the  element  which  issues  a 
CLEAR'RESET  signal  to  supply  the  processor  with  its  start  address.  This  approach  allows  the 
most  flexibility  for  the  processor  while  minimizing  the  necessary  hardware. 

8.  Processor  Functional  Design  Summary 

This  functional  design  offers  a powerful  but  realizable  microprocessor  for  the  avionics 
application.  Functionally,  the  DP  M processor  is  a 16-bit.  two's  complement.  8-general-register 
machine.  These  8 general  file  registers  are  used  as: 

1 -Program  Counter  (register  7) 

1 -Interrupt  and  Temporary  Stack  Pointer  (register  6) 

6- General  Purpose  Accumulators  (registers  0 through  5) 

7- Standard  Format  Index/Base  Registers  (registers  1 through  ?>* 


*Or,  if  the  direct  indication  is  changed  from  0 to  7,  then  registers  0 through  7. 
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8 Load'Store  Direct  Short  Base  Registers  (registers  0 through  7) 

The  primary  data  types  are  single  bits  and  full  16-bit  words  Neither  double  precision  (two-word) 
arithmetic  nor  byte  (character)  processing  has  been  included  due  to  their  expected  low  usage 
Floating-point  operations  have  been  omitted  also  because  the  additional  hardware  would  extend 
the  processor  beyond  what  would  be  considered  reasonable  for  a commercially  available 
microprocessor  for  the  1978  80  tune  period.  The  primary  candidates  for  instruction  set 
expa  on  would  be  a double  precision  add  followed  by  double  word  load  and  store  operations 
Of  lesa  importance  would  be  double  precision  subtract  and  byte  manipulation.  The  DP  M base 
line  instruction  formats  arc  summarized  in  Figure  38  and  the  operations  are  summarized  in 
Tables  7 and  8 The  DP  M processor  has  a full  complement  of  operations  composed  of  40  basic- 
instructions  of  the  following  types: 

Arithmetic 
Logical  (Boolean) 

Data  Transfer 

Shifts  (logical  and  arithmetic) 

Bit  Manipulation 
Compare 

Program  Transfer  (conditional  and  unconditional) 

Subroutine  Linkage 
Control  (status  word) 

Interrupt  (Context  Switching  via  stack) 
lnput'Output 

The  DP  M instruction  set  reflects  the  special  emphasis  that  is  placed  on  several  design 

areas: 

Maximization  ol  instruction  code  efficiency  both  execution  time  and  memory  usage 
(extended  short  instructions) 

Basic  read  modify  write  memory  operations  (bn  and  STTM) 

Lase  of  access  to  small  local  workspace  (register  fi1"  and  LDS  STFoj 
Loop  control  and  indexing  (RIA  and  IBNS) 

Subroutine  linkage  (B1LR) 

Interrupt  handling  (multilevel  with  trjp  vector 

No  self-modifying  -'ode  required  ve.g..  instructions  whose  characteristics  are 
determined  at  run  time)  an  important  feature  in  read-only  memory 
applications. 

Flexible,  efficient  addressing  mode  IR.  RI.  RIA.  C,  D.  LX) 

As  was  observed  in  the  programs  analyzed,  the  extended  short  format  instructions  were 
used  between  40  and  55  percent  of  the  time  which  contributed  to  a 30  to  35  percent  savings  of 
program  memory  and  25  percent  savings  in  program  execution  time.  The  instruction  set  has  been 
selected  to  make  subroutine  iinkage  easy  and  to  support  the  basic  types  oi  data  structures  such 
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us  lists,  stacks,  and  queues.  The  interrupt 
structure  uses  un  interrupt  stuck  to  suve  the 
program  stute  and  to  allow  multiple  nesting  of 
nterrupts. 

Tile  intent  of  the  design  effort  was  that 
functionally  DP/M  base  line  processor  be  a 
powerful  and  flexible  machine.  At  the  same 
time,  special  consider. tion  has  been  given  to 
seeing  that  the  processor  is  not  too  complex  to 
be  implemented  as  one  to  two  microprocessor 
chips. 

B.  PROCESSOR  PHYSICAL  DESIGN 

The  processor  physical  design  is 
characterized  by  the  actual  hardware  registers 
and  memories,  arithmetic  and  logic  units,  and 
the  data  an.1  control  paths.  There  may  or  may 
not  be  a close  correspondence  between  the 
actual  hardware  architecture  a -id  the  functional 
architecture  that  the  programmer  sees.  As 
previously  cited,  the  register  file  may  actually 
be  part  of  the  main  memory  rather  than  being 
an  actual  hardware  register  file.  Thus,  the 
actual  hardware  may  be  less  than  the 
programmer  thinks  it  is.  On  the  other  hand, 
there  are  frequently  a number  of  int-rnal 
working  registers  that  hold  intermediate  results 
that  ar  never  seen  by  the  programmer. 
Figure  45  shows  the  overall  general  block 
diagram  of  the  DP/M  PE  processor.  It  is 
composed  of  the  instruction  register  and 
decode  section,  processor  control  section, 
micro  data  processor,  and  status  register.  Two 
primary  considerations  are  the  construction  of 
the  processor  control  (hard-wired  versus 
micro-controlled)  and  whether  the  general 
register  file  should  be  in  the  micro  data 
processor  or  in  main  memory.  Based  on 
current  trends  in  processor  design,  the 
processor  control  will  use  a combination  of 
micro  code  and  programmable  logic  arrays 
(PLAs).  PLAs  are  especially  useful  for  control 
applications  in  semiconductor  devices 
(combinatorial  logic)  where  !t  is  a requirement 
to  alter  (change  or  correct)  the  control  without 
completely  redesigning  the  chip.  This  flexibility 


Figure  44.  Basic  Instruction  Cycle 
With  Interrupts 
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Fiim re  45.  Processor  Block  Diagram 


is  enhanced  by  the  high  device  packing  density  available  with  PLAs.  The  recommended  approach 
for  the  DP/M  processor  is  the  use  of  a combination  of  the  following  control  techniques: 

( 1 ) hardwired  data  paths,  registers,  and  ALU 

(2)  PLAs  for  control  decode  at  the  clock  level 

(3)  Read  Only  Memory  (ROM)  for  clock-to-clock  sequential  control. 

Furthermore,  it  is  recommended  the  micro-data  processor  have  a hardware  register  File  instead  of 
a virtual  (memory)  register  File.  An  8-word  by  16-bit  hardware  register  file  increased  the  overall 
processor  gate  count  by  slightly  more  than  10  percent  and  offers  a potential  two  to  one  increase 
in  performance.  The  following  paragraphs  discuss  the  PE  instruction  execution  cycle,  the 
hardware  block  diagram  of  the  processor  module,  and  develop  a gate  level  complexity  estimate 
for  the  processor. 

1.  PE  Instruction  Cycle 

The  DP  M PE  instruction  cycle  can  be  divided  into  those  phases  shown  in  Figure  46.  Some 
of  these  operations  may  actually  be  overlapped  in  time;  however,  it  is  convenient  to  view  them 
as  sequentially  e>ecuted  The  four  major  operations  in  the  instruction  cycle  are. 

Inst  ruction  decode  which  consists  of  determining  what  is  the  First  action  that  the 
new  instruction  requires.  This  first  action  will  be  the  derivation  of  opeiands 
for  use  during  the  instruction  execution  cycle. 

Operand  derivation  which  is  the  generation  or  fetching  of  an  address  or  data  to  be 
used  during  operation  execution. 

Operation  execution  which  uses  the  address  or  data  supplied  by  the  operand 
derivation  and  carries  out  the  desired  operation  specified  by  the  instruction. 

Instruction  fetch  which  consists  of  loading  the  instruction  register  with  the  memory 
word  that  the  program  counter  is  pointing  at  and  incrementing  the  program 
counter. 

a.  Instruction  Fetch  Lookahead 

The  simplest  form  of  pipelining  or  lookahead  is  instruction  fetch  lookahead.  This  can  be 
accomplished  by  combining  the  execution  of  the  current  instruction  with  the  fetching  of  the 
next  instruction.  This  lookahead  is  possible  as  long  as  the  current  execution  does  not  involve 
mam  memory'  (e.g..  a store  instruction)  or  the  program  counter  (branch  instruction).  In  theory, 
tins  could  result  in  a two  to  one  improvement  in  the  execution  time  for  single  word  instructions 
(extended  short  and  register-io-rtgister  operations  that  are  not  branch  or  store  instructions).  This 
can  amount  to  approximately  25  percent  of  the  typical  mix  of  avionic  program  instructions.  In 
practice,  due  to  instruction  mix  and  execution  overhead,  the  improvement  is  limited  to  about  a 
10-  to  20-percent  improvement. 

h.  Instruction  Execution  Time  With  Instruction 

Fetch  Lookahead 

The  execution  time  of  an  instruction  is  the  length  of  time  to  go  completely  through  the 
instruction  execution  cycle.  The  instruction  fetch  time,  without  lookahead,  is  independent  of  the 
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FETCH 

LOOKAHEAD 


Figure  46.  Basic  Instruction  Cycle 


previous  01  the  next  m<-tnuti<  n Hus  i>  dots 
not  mutter  whether  wi  mcuMiie  between  the 
start  of  instruction  decode  01  between  the 
start  of  instruction  teteh.  With  the  elicit  of 
instruction  letch  lookahead  on  -null  instnk- 
tu>ns  as  branch  and  stoie.  the  instruction  letch 
time  is  dependent  hi  the  preceding  instruction 
In  this  case,  it  is  best  to  deline  instuictio.i 
execution  time  us  the  tune  between  starts  ol 
instruction  decoding  This  makes  the  execution 
time  ot  an  instruction  independent  ot  the 
previous  and  the  next  instruction,  e'en  wit n 
instruction  letch  lookahead 

c Interrupts  With  Instruction  l etch 

lookahead 

Proper  handling  of  internally  generated 
(within  the  processor  module!  interrupts  (i.e., 
overflow  I can  present  special  problems  with 
instruction  fetch  lookahead.  This  problem 
results  when  the  next  instruction  has  already 
been  fetched  and  the  program  counter 
incremented  before  any  execution  dependent 
interrupt  can  be  detected  The  best  solution  to 
this  problem  is  to  go  ahead  and  fetch  the  next 
instruction  and  increment  the  progiam  counter 
while  the  current  instruction  completes 
execution.  Then,  during  instruction  decode  and 
lust  before  the  operand  derivation  starts  foi 
the  next  instruction,  a t«*st  is  made  lor  pending 
interrupts.  If  there  is  an  interrupt  pending, 
execution  ot  the  new  instruction  just  t etc  lied  is 
aborted,  the  program  counter  is  restored  to  its 
previous  value  (i  e..  it  is  decremented),  and  (In- 
appropriate interrupt  service  sapience  is 
performed  ( figure  44) 


Arithmetic  overflow  is  the  primary  internal  <to  the  proiow.ii  inturup  mu  It.  it 
deserves  special  attention  in  the  design  ot  the  processor  There  are  (lire  overflow  situations  ol 
interest  to  the  programmer  The  simplest  is  where  overflows  are  to  be  ignored  suili  as  during 
modulo  number  processing  of  angles  The  next  situation  ;s  an  overflow  during  a senes  ot 
arithmetic  calculations.  Since  this  case  can  be  an  abnormal  situation,  u i-  ltnpoilant  that  its 
processing  overhead  be  minimized.  The  normal  way  of  processing  these  two  cases  n to  eithei 
provide  a maskable  overflow  interrupt  and  or  to  save  tile  overflow  stilus  toi  subsequent  testing. 
The  iast  situation  ot  interest  is  an  overflow  during  the  execution  ol  a oaiticular  institution 
where  immediate  corrective  action  must  be  taken.  An  example  is  suttw.re  multiple  precision 
routines  This  case  is  best  handled  by  following  the  instruction  that  max  c itise'  an  overflow  with 
an  overflow  test  instruction  <e.g  . branch  on  overflow!  In  this  iasi.  .in  ovc  flow  interrupt  should 


be  suppressed,  since  it  is  being  tested 
explicitly..  Because  the  next  instruction  has 
already  been  fetched  before  testing  ior  an 
interrupt,  it  is  a simple  matter  to  test  for  an 
overflow  followed  by  a branch-on-overflow 
instruction.  In  the  DP/M  Processing  Element, 
the  overflow  followed  by  the  bianch-on- 
overflow  instruction  is  tested  before  the  test 
for  interrupts  (Figure  47).  The  branchon- 
overflow  instruction  will  clear  the  overflow  bit 
Thus,  it  is  not  necessary  to  change  the 
overflow  interrupt  mask  if  there  is  to  be 
immediate  explicit  handling  of  overflow.  In 
addition  to  the  intraprocessor  overflow 
interrupt  condition  affecting  the  instruction 
execution  cycle,  a similar  event  can  occur  with 
an  1 O instruction  that  causes  either  an 
interrupt  to  be  generated  <10  time  out  or 
acknowledge)  or  requires  only  a condition  code 
setting  response. 

d.  Instruction  Microcode  Sequence 

The  previously  described  DP  M instruc- 
tion execution  cycle  shown  in  Figure  47  was 
extended  during  the  design  effort  to  include 
sample  microcode  sequences  for  different  PE 
instructions  A brief  review  of  the  microcode 
control  sequence  defined  for  the  PE  is 
presented  in  this  subsection.  This  microcode 
sequence  applies  to  *ue  physical  hardware  of 
the  processor  defined  .n  Subsection  IV.B.2. 

The  DP  V micro  control  sequences 
philosophy  anticipates  the  more  frequently 
used  PE  instructions  and  provides  lookahead 
features  to  minimize  the  execution  time  for 
these  operations.  The  micro  control  sequence 
starts  when  a new  instruction  has  been  fetched 
and  placed  in  the  instruction  register  and  the 
sign-e:,tended  I-field  of  the  instruction  has 
been  loaded  into  an  internal  working  register, 
the  pMQ.  The  instruction  decode  then 
generates  an  entry  point  to  the  beginning  of 
.he  appropriate  microcode  sequence.  This  entry 
point  is  also  used  in  response  to  an  interrupt 
or  to  correspond  to  the  beginning  of  a load 
store  direct  short,  extended  short,  operand' 
address  derivation,  or  a regisier-to-register 
standard  format  instruction  execution. 


Figure  47,  DP/M  Instruction  Cycle 
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Figure  4K  shows  the  microcode  sequence  tor  i DP'M  d.ii.t  indexed  operand  derivation  cycle. 
Remember,  the  instruction  fetch  cycle  is  part  ot  the  final  operation  of  the  preceding  instruction, 
and  note  that,  during  the  instruction  decode  the  register  pointed  to  by  the  T-tield  of  the 
instruction  is  loaded  into  the  micro  accumulator  (pAC).  This  action  allows  the  bypassing  of  the 
operand  derivation  cycle  for  register-to-register  instructions,  thus  saving  several  micro  steps  and 
reducing  instruction  execution  time. 

Figure  49  shows  the  execution  portion  of  a LOAD  insV-iction.  while  Figure  50  shows  the 
execution  portion  of  an  ADD  instruction.  Note  that  during  the  operand  derivation  cycle,  the 
operand  was  placed  in  the  nAC  and  the  instruction  execution  microcode  entry  point  was 
generated.  For  these  simple  instruction  operations,  only  a single  micro  step  is  required.  Also, 
because  of  independent  program  counter  and  addiess  selection  output  control,  the  fetching  of 
the  next  instruction  is  overlapped  with  the  execution  of  the  current  instruction. 

As  previously  noted  the  p.VlQ  register  will  have  been  loaded  with  the  sign  extended  I-field 
of  the  instruction  during  instruction  fetch.  Also,  at  the  end  of  the  decode  cycle,  the  ^ AC  will  be 
loaded  with  the  register  pointed  to  by  the  T-field  of  the  instruction.  Because  of  this,  the 
Load  Store  Direr:  Short,  extended  short,  and  standard  format  register-to-register  operations  can 
be  executed  imm  ‘diately  after  decode. 

Figures  51,  52.  and  53  are  examples  of  the  micro  sequences  for  the  following  instructions: 
Load  Direct  Short 
Load  Constant  Short 
Load  Register. 

A comparison  of  Figure  49  with  Figure  53  reveals  that  the  standard  Load  instruction  sequence  is 
independent  of  the  operand  derivation. 

2.  Processor  Hardware  Design 

The  preceding  paragraphs  described  the  functional  design  of  the  instruction  execution 
cycle,  and  the  control  philosophy  for  the  DP  M PL  processor  module.  This  subsection  presents 
the  hardware  block-level  design  and  complexity  estimates  for  the  processor.  The  processor  is 
composed  of  four  basic  units  as  shown  in  Figure  45.  These  units  are  the  instruction  register 
select  and  decode,  processor  control,  micro  data  processor,  and  status  register. 

a.  Instruction  Register.  Select,  and  Decode  Block 

The  instruction  register,  select,  and  decode  block  (Figure  54)  is  composed  of  the 
instruction  register,  the  instruction  decoder,  and  the  register  select  multiplexer.  The  instruction 
register  is  composed  of  a single-bit  latch  for  external  interrupts,  a 10-bit  latch  tor  the  X,  C,  and 
M fields,  and  two  3-bit  up-down  counters  for  the  T-  and  R-helds.  The  external  interrupt  is 
sy  nchronized  by  latching  it  into  a register  when  the  new  instruction  is  loaded.  The  counters  are 
used  for  the  multiple  word  accesses  to  the  register  file  for  double  shifts,  multiply,  divide,  and 
push  pop  multiple  instructions. 

The  instruction  decoder  derives  its  inputs  from  the  instruction  register  (including  the 
external  interrupt  flag)  and  one  bit  of  muro  control  which  is  used  to  force  a second  operation 
decode  during  the  execution  of  standard  format  instructions.  The  overflow  mask,  overflow 
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Figure  4.S  Direct  Indexed  Operand  Derivation 
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Figure  49.  Load  Instruction  Execution 


condition,  device  and  memory  error  masks.  1 O select,  transfer  time  out.  and  memory  time  out 
flag  lines  are  also  input  into  the  instruction  decode  logic.  The  instruction  decode  logic  is 
implemented  as  a programmable  logic  array  (Pl.A).  has  25  input  variables,  and  generates  an  8-bit 
micro  code  entry  point  and  a data  line  into  the  memory  timeout  Hag.  There  are  six  classes  of 
micro  memory  entrv  points  generated  < interrupt,  load  store  direct  short,  extended  short,  derived 
operand,  deriveu  address,  and  standard  format  operation)  that  take  approximately  80  logical 
minterms.  Lastly,  there  is  the  register  selection  multiple v^r  which  is  a dual  three-input 
multiplexer. 
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Figure  50  Add  Instruction  Execution 


b /‘race  wo.  ('antral 

The  processor  control  is  shown  in  Figure  55.  It  is  composed  of  the  micro  sequence  control 
(shown  in  Figure  56)  and  the  micro  memory. 

The  micro  sequencer  is  an  h-bit-wide  microcode  address  controller.  It  is  composed  of  an 
adder,  j muo  link,  a micro  address  multiplexer,  a micro  address  register  and  a micro  control 
decoder.  The  adder  is  used  to  increment  the  micro  address  register  and  generate  relative 
branches,  I he  micro  link  is  used  to  hold  a return  address  for  micro  looping  and  micro 
subroutines.  The  micro  address  multiplexer  selects  the  source  of  the  next  micro  program  address. 
I his  source  can  be  the  instruction  decoder,  an  absolute  or  relative  branch  address  supplied  by 
the  micro  code,  the  next  micro  instruction  in  sequence,  or  the  micro  link  address.  Note  that  the 
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Figure  51.  Load  Direct  Short 
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Figure  52.  Load  Constant  Short 
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* NOTE  THAT  THIS  EXECUTION  IS  THE 
SAME  AS  FOR  ANY  OTHER  DERIVED 
OPERAND  LOAD  INSTRUCTION  BE- 
CAUSE IT  ALWAYS  HAS  THE  DERIVED 
OPERAND  IN  THE  MICRO  ACCUMULA- 
TOR (mAC). 


Figure  S3.  Load  Register 


branch  address  (relative  or  absolute)  shares  micro  code  bits  with  the  other  parts  of  the  processor. 
This  reduces  the  number  of  micro  memory  bits  while  requiring  an  extra  clock  in  the  case  of  a 
branch  instruction.  Because  of  the  instruction  decoder  for  microcode  entry  points  and  the  micro 
link  register  for  iterative  loop  closing,  only  special  cases,  such  as  multiply  and  divide  fixup, 
require  the  use  of  the  micro  branch.  The  micro  sequence  control  has  its  own  decode  which  has  7 
control  lines  from  micro  memory  and  14  internal  and  external  condition  lines  it  can  test.  This 
decoder  is  also  a PLA  which  has  approximately  35  logical  minterms  a.id  6 outputs  which  control 
the  adder,  multiplexer,  and  the  two  registers. 

Previous  design  experiences  with  instruction  complements  similar  to  the  DP/M  PF.  indicate 
that  a 256-word  control  memory  will  be  adequate  for  the  processor  micro  memory.  A 
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instruction  register,  select  and  decode  diagram 


n MEMORY  INTERRUPT 


Figure  54.  Initruction  Register,  Select  anil  Decoder  Diagram 
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Figure  55.  Processor  Control  Diagram 
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Figure  $6.  Micro  Sequencer  Control  0(SC) 


32*bit-wide  micro  control  word  will  suffice  based  upon  the  different  local  decode  sequence. 
Therefore,  the  recommended  micro  memory  for  the  processor  is  32  X 256  (8192)  bits  of  ROM 

c.  Micro  Data  Processor 

The  DP  M PE  micro  data  processor  reflects  a conventional  design  approach  for  a micro 
controlled  processor.  It  contains  its  own  local  memory  [the  register  file  (RF)],  a program 
counter  (PC)  which  is  a counter  rather  than  a register,  an  arithmetic  logic  unit  (ALU),  and  two 
working  registers  [the  micro  accumulator  (jiAC)  and  the  micro  MQ  register  (pMQ)[.  The  PE 
memory  and  I'O  devices  are  accessed  by  the  processor  as  if  they  were  externally  addressable 
deuces  via  the  “address”  and  "data”  lines.  All  of  the  data  paths  are  16  bits  wide  except  as 
shown  in  Figure  57,  A few  special  points  worth  noting  are 

The  6 bits  of  the  internal  processor  status  word  are  merged  together  with  the  30 
external  status  word  bits  (brought  t.irough  the  mAC)  by  the  B multiplexer  of 
the  ALU.  Also,  the  internal  status  word  is  loaded  from  the  output  of  the 
ALU  when  the  external  status  word  bits  are  loaded  via  the  data  lines. 

The  address  lines  can  be  driven  from  either  of  the  two  internal  working  register*,  the 
program  counter,  or  the  internal  interrupt  trap  location  addresses  which  are 
supplied  by  the  micro  code.  When  the  addres'  lines  are  decoded  from  the 
p.MQ.  only  the  lower  eight  bite  are  used  sinc»  tins  corresponds  to  either  the 
directory  address  of  the  BILR  instruction  subroutine  or  the  MIC  M(X 
command  address  word  (CAW). 
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The  shift  count  and  control  are  the  lower  half  of  the  derived  operand.  This 
information  is  loaded  from  the  pAC  which  contains  the  derived  operand.  This 
can  be  done  at  the  same  time  the  p AC  (and  possibly  also  the  pMQ)  are  being 
loaded  via  the  ALU  with  the  values  to  be  shifted.  Note  that  the  shift  iteration 
counter  is  also  used  during  multiply  and  divide  instructions. 

The  pAC,  pMQ.  PC'.  RF,  and  data  out  (as  well  as  the  internal  status  word)  can  all  be 
loaded  with  the  output  from  the  ALU.  I.i  addition,  the  pAC  can  be  loaded 
with  the  output  of  the  ALU  shifted  left  or  right,  as  well  as  the  data  in.  The 
p.MQ  can  also  be  shifted  (left  or  right)  or  loaded  with  the  sign-extended  8-bit 
immediate  data  field  of  the  :n;truction. 

The  micro  data  processor  control  decode  has  10  input  lines  to  control  the  20  internal 
gating  lines.  Based  on  previous  design  experience,  approximately  100  minterms  will  be  required 
to  implement  this  control  function. 

d.  Status  Register  and  Control 

The  status  register  and  its  control  (Figure  58)  is  composed  of  a six-bit  register  plus  the 
status  logic.  The  status  logic  has  1 1 inputs.  6 outputs,  and  approximately  32  minterms. 

3.  Processor  Complexity  Estimate 

Each  hardware  block  of  the  DP  M PE  processor  was  examined  and  an  estimate  of  its 
approximate  device  complexity  was  computed  based  upon  TTL  (Transistor-Transistor  Logic) 
equivalent  part  and  device  counts.  Table  1 1 summarizes  the  factors  used  to  estimate  processor 
complexity  in  terms  of: 

Logic  gates 

PLA  terms 

ROM  terms 

RAM  bits. 


TABLE  II.  COMPLEX! TV  FACTORS 
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Each  of  these  descriptive  terms  is  relatively  technology-independent  and,  consequently,  has  been 
selected  to  compute  the  processor  complexity.  As  background  information,  a brief  review  of  the 
impact  on  device  complexity  of  PLAs  and  ROMs  is  given. 

The  semiconductor  device  construction  of  a PLA  and  ROM  are  quite  similar  (see 
Figure  59). 

In  the  case  of  the  ROM,  all  possible  minterm  combinations  of  the  address  lines  are 
generated,  i.e..  address  decode  (min terms  = words  = 2*ddress  hnc$).  The  data  read  from  the  ROM 
corresponds  to  selecting  those  minterms  (words)  that  are  ORed  together  to  form  the  output 
(bits).  The  device  area  for  an  ROM  can  be  divided  into  the  address  decode  (word  select)  area  and 
the  data  area.  A rough  approximation  of  the  address  decode  area  can  be  estimated  by  taking  the 
number  of  address  lines  (true  and  complement)  times  the  number  of  words  (minterms).  This 
would  lead  to  an  area  that  would  corespond  to- 

Area  ~ 2 * address  lines  * words 

The  multiplicative  factor  of  2 is  used  ccount  for  both  the  true  and  complement  of  each 
address  line  that  must  be  used  for  a • ess  i'  -.-  Je.  Since  all  possible  addresses  (minterms)  must 
be  generated  and  there  is  no  req  * /:  f;r  programming  the  address  decode  logic,  this  can  be 
accomplished  efficiently.  Thu  c-r  ‘.fio.i  permits  approximately  a two-to-one  reduction  in  the 
area  required  for  the  address  decode  Similarly,  the  data  area  can  be  estimated  by  taking  the 
number  of  words  times  the  number  of  outputs;  i.e..  the  data  area  is  proportional  to  the  number 
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1 of  bits  Si  iky  the  data  area  of  the  ROM  must  he  programmable  and  can  torm  am  pattern,  there 

! is  not  the  coric'ponding  area  reduction  puss. hie  as  with  the  address  decode  1 he  area  ol  an  ROM 

^ is  thus  going  to  he  measured  in  "ROM  1 1 RMS'-'  wlneli  is  a measure  ot  the  word  decode  area  and 

i the  data  area 

[ 

j ROM  II  RM  = word  * (outputs  a address  lines) 

! hits 

typically.  the  number  ot  address  lines  is  nearly  equal  to  the  number  ol  output  lines  theiefore. 
the  area  tor  the  address  decode  is  a^out  the  same  as  the  aiea  tor  the  data 

; I he  PI  A is  similar  to  an  ROM  except  not  all  possible  minlerms  (wordsi  are  generated,  and 

the  minternis  to  he  generated  are  programmable  llius.  both  the  minterms  and  the  sum  of 
nunterms  are  programmable.  I Ins  structure  permits  random  logic  to  be  mask. -programmable.-  as  is 
the  data  in  a memory.  the  minterms  are  also  programmable,  there  is  not  the  two-to-one 

reduction  in  decode  area,  as  there  was  in  the  case  of  the  ROM  The  FLA  terms  must  include  the 
two-to-one  expansion  ot  the  input  lines  into  the  true  and  complement  signals.  The  equivalent 
area  factor  lor  a PI.  A term  is 

PI. A 1 1 RM  = minterms  * (outputs  + 2 * inputs) 

An  •‘stimate  ot  the  processor  complexity  is  given  in  Table  12.  including  the  relative 
f complexity  ot  the  various  sections  of  the  processor.  The  total  processor  device  complexity  is 

estimated  to  be 

Ci.Al  I S 1.541 

PL  A ROM  II  RMS  22.2K 

RAM  bits  112. 

’Aith  current  1 1L  technology,  there  is  about  a 10.1  ratio  between  the  device  area  tor  gates 
and  PLA  ROM  II  RMS.  with  a RAM  bit  considered  smaller  than  a gate.  Using  these  guidelines 
lor  Til  technology,  the  processor  (areawisel  would  correspond  to  3.H73  gate  equivalents  These 
ratios  are  strongly  technology  dependent,  consequently,  this  number  is  not  appropriate  to  use  for 
other  than  TTI.:.  I he  PI  As  and  ROMs  tend  to  dominate  the  active  device  count  ■ en  though 
they  pack  very  well  due  to  their  structural  regularity.  II  desirable,  several  techniques  can  be  used 
to  reduce  the  si/e  ol  the  Pl.As  and  ROMs.  One  method  of  PLA  si/e  reduction  is  to  limit  the 
PLA  flexibility  by  not  allowing  all  inputs  to  control  all  outputs.  The  micro  data  processor  PLA 
could  he  cut  in  halt  by  partitioning  it  into  two  sections,  each  with  5 inputs.  10  outputs,  and  50 
ninterm  PI  As.  Thus,  lor  a -light  reduction  in  flexibility,  substantial  chip  area  reductions  can  be 
achieved.  Similar  techniques  can  be  applied  to  the  ROM  program,  not  all  256  words  must  have 
32  hits.  I or  instance,  many  ot  the  blocks  of  micro  operations  have  the  >ame  bit  pattern  on  most 
ol  their  data  lines.  As  an  example.  AM).  OR.  ADI),  and  SUBTRACT  operations  require  identical 
micro  control  patterns  except  tor  a tew  ot  the  ALU  and  status  control  lines.  One  of  the  Texas 
Instruments  micro  controlled  processors  that  was  recently  designed  took  advantage  of  this 
teature  hy  splitting  the  micro  control  lines  between  a 32-word  ROM  and  a 256-word  ROM.  The 
32-word  ROM  controlled  the  maiortty  ot  the  micro  control  lines  while  the  256-word  ROM 
controlled  the  tew  lines  that  were  unique  to  a particular  operation  and  or  required  multiple 
clock  operations.  These  techniques  can  be  applied  to  the  ROM  to  reduce  its  active  device  area 
while  imposing  some  loss  in  flexibility  in  applying  the  ROM  to  processor  control  operations. 
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TABLE  12.  PROCESSOR  COMPLEXITY  SUMMARY 


PLA 

ROM 

Terms 

Terms 

RAM 

GATES 

(000's) 

(000*) 

BITS 

Instruction  Register  and  Decode 
Instruction  Register 

120 

El.  X.  C.  and  M Fields 

66 

T and  R Fields 

60 

Memory  Time  Out  Flag 
Decode  fPLA) 

6 

4.7 

Inputs  25 

Minterms  80 

Outputs  9 

Register  Select 

11 

137 

4.7 

Processor  Control 

Micro  Sequencer 

228 

Adder 

88 

Micro  Link 

48 

Micro  Address  Multiplexer 

44 

Micro  Address  Register 
Control  Decode  (TLA) 

48 

1.7 

Inputs  21 

Minterms  35 

Outputs  6 

Micro  Memory  (256  X 32) 

10.2 

228 

1 J 

10.2 

- 

Micro  Data  Processor 

Program  Counter 

160 

Register  File  (7  X 16) 
ALU  and  Multiplexers 

438 

112 

Micro  Accumulator  and  MQ 

320 

Address  Multiplexer 

84 

Data  I/O 

50 

Shift  Control 

68 

Register  (3) 

18 

Counter  (5) 

Control  Decode  (TLA) 

50 

4.0 

Inputs  10 

Minterms  100 

Ouiputs  20 

1.120 

4.0 

\\2 

Status  Register 

Register  and  Multiplexer  (6) 
Status  Logic  (TLA) 

56 

1.6 

Inputs  22 

Minterms  32 

Outputs  6 

56 

1.6 

- 

Processor  Total 

1,541 

12.0 

10.2 

112 

152 


'mother  technique  «.an  he  applied  to  the  proeessoi  to  icduce  the  ehip  complexity  by 
dividing  the  proeessoi  into  two  nearly  equal  devices.  This  tan  he  done  by  putting  the  micro  d.ita 
I imcssoi  plus  the  register  specification  held  of  the  instruction  icgister  on  one  c hip  and  the 
remaining  functions  on  a separate  chip.  Using  1 I'L  complexity  as  a basis  toi  estimation,  this 
partitioning  y lelds 


Data  Pi i s. esv > i Chip 

Mkiu  Data  Pumsvi  1.643 

Copy  lit  T&R  fields  60 

Regisici  Select  II 

1 .'’03  gales 

C iiniio!  Chip 

Total  Processor  3.873 

less  Micro  Data  Processor  1 .632 

l ess  Register . Select  II 

2 230  gates 


This  partitioning  possibility  is  shown  later  in  Section  VI. 

C.  PE  MEMORY  SPECIFICATION 

While  there  is  a lairly  clear  distinction  between  the  timet  tonal  and  physical  architecture  ol 
the  PI  processor,  the  PI  has  j relatively  simple  one-level  main  memory  concept.  The  design  ol 
the  DP  M PI  memory  subsystem  considered  the  following  items 

Use  and  type  ol  ineinoii-  s 
Si/e  and  performance 
Protection  and  error  detection 
Initialization. 

I he  memory  subsystem  can  be  eharacten/ed  in  teims  ol  Ms  likely  use  by  the  ptocessot 
instruction  and  operational  sottware.  I he  luiktional  use  ol  PI  memoty  can  be  divided  into  the 
following  categories 

Scratch  pad  memory  (temporal y values,  tiles,  slacks) 

Data  (variables  and  constants! 

Program  l instruction  storage) 

The  types  ot  main  IT  memory  available  ate 

High-Speed  Read  W'rite  Random  Access  Memoty  ( I IS- K AM  l 
Low-Speed  Read  Write  Random  Access  Meinoiy  (I.S-RAMt  Main  Memory 
Read-Only  Random  Access  Memory  (ROM). 

The  relationship  between  the  use  and  the  type  ol  memoiv  is  shown  in  I able  13.  I wo 
items  discussed  previously  in  the  processor  design  are  memoiv  tvpe  luiu turns  the  micro  program 


control  store  and  the  hardware  register  file.  In 
the  DP  M PH.  the  high-speed  RAM  corresponds  to 
the  register  file  which  is  part  of  the  processor, 
the  lower-speed  RAM  and  the  POM  correspond 
to  main  memory.  The  bootstrap  loader  is  a part 
of  the  I ()  subsystem,  the  processor  micro  control 
storage  memory  and  physically  write-protected 
main  memon  are  internal  PI  units  requiring 
ROM  (unctions 

The  recommended  si/c  of  the  DP  M 
memory  module  is  presently  X.l‘*2  or  xk  words.  Past  studies  indicate  a large  portion  of  avionic 
processing  algorithms  are  amenable  to  this  segment  si/e  of  computer  memory  . I he  limited 
avionic  software  si/mg  analysis  that  occurred  during  the  design  also  found  little  reason  to  diff  i 
from  the  Xk  memory  module  specification.,  As  technologies  improve  and  memory  devices 
increase  packing  densities  and  reduce  cycle  times,  the  8k  module  offers  the  most  use  in  applying 
DP  M to  avionic  applications.  T he  projected  access  time  for  the  DP'M  PI:  memory  is  expected  to 
range  front  I 3 to  I ’ microsecond  and  otters  satisfactory  PI  instruction  execution  times. 

f or  high-performance  pro.  essors.  it  *s  not  uncommon  to  have  the  memory  segmented  into 
several  sections  (possibly  on  a functional  basis).  In  this  case,  the  memory  has  several  access  ports. 
Typically,  one  port  will  be  assigned  to  instruction  fetching,  another  to  processor  data,  and  the 
others  to  high-speed  I/O.  Projected  throughput  and  partitioning  requirements  for  the  DP  M 
system  do  not  mstify  the  use  of  such  a segmented  multiple-port  memory  subsystem.  Therefore, 
the  recommended  Ph  memory  subsystem  has  only  a single  port  accessible  to  users  via  the 
internal  PI  bus. 

I.,  Memory  'fotection 

Ihe  subject  of  memory  protection  mechanisms  was  reviewed  fo:  the  DP  M design.  The 
requirement  for  memory  protection  wili  depend  upon  the  use  of  the  PH  in  a given  avionic 
system,  and  the  demand  of  a given  application  for  prevention  of  unauthorized  writing  into 
read  write  memory.  It  a suitable  read  write  memory  requires  such  a protection  in  the  application 
of  the  DP  M.  the  following  guidelines  are  suggested. 

Memory  write  protection  generally  takes  one  of  two  forms.  The  protection  can  be 
classified  as  either  word  or  address  protection.  In  the  case  of  word  protection,  each  word  has  a 
bit  attached  to  it  which  specifies  whether  it  can  be  written  into  or  not.  With  address  protection, 
there  is  some  form  of  address  map  that  specifies  which  regions  of  memory  are  write-protected 
and  which  are  not.  The  protected  regions  are  generally  specified  by  either  a set  of  registers  which 
point  to  the  ends  of  the  protected  region(s)  or  a bit  map  which  specifies  whether  individual 
blocks  (pages)  of  memory  are  protected  or  not.  With  core  memories,  it  is  common  to  use  word 
protection  since  there  is  no  performance  penalty  in  reading  a word  before  writing  into  it.  This  is 
not  true,  though,  for  semiconductor  memories  such  as  will  be  used  for  DP/M:  it  takes  nearly 
twice  as  long  to  do  a read  before  write  as  a simple  write  This  is  because  there  is  basically  no 
restore  cycle  associated  with  a semiconductor  memory.  In  addition,  the  structure  of  the  DP/M 
memory  space  leads  itself  to  region  protection.  For  the  DP/M.  low  address  memory  can  be  used 
for  program  and  interrupt  trap  vectors  and  high  address  memory  can  be  used  for  BIU  message 
control.  This  means  that  the  two  ends  of  the  memory  space  need  to  be  read-only  protected 


TABLE  13  MEMORY 
USE  VERSUS  TYPE  TABLE 


Scratch 

Data 

Variables 

Constants 

Protrani 


HS-RAM  LS-RAM  ROM 


wink-  the  center  in  read/write.  Another  com- 
mon  situation  is  where  the  reverse  is  true  and 
ihe  center  is  read-only  protected  and  the  ends 
are  read  write.  Both  of  these  situations  can 
easily  he  handled  with  a pair  ol  registers  and 
address  comparators.  This  is  the  approach  that 
is  proposed  tor  the  DP.'M  RAM  type  memory 
that  requires  write  protection.  This  function,  it 
required,  will  he  implemented  on  the  memory 
control  and  timing  chip. 

2.  I rror  Detection 

Memoiies  normally  have  some  lorm  «»t 
emu  detection  and.  in  some  cases,  even  error 
correction.  Ihe  error  detection  and/or  correc- 
tion is  appropriate  for  the  DI’/.M  IM  to  increase 
rehahihty  and  fault  detection.  Semiconductor 
memory  errors  are  normally  clnp-oriented. 
That  is,  a memory  error  is  mainly  due  to  a 
single  chip  that  has  a single  hit  or  a whole  data 
row  and  or  column  that  is  marginal  or  has 
failed.  Thus,  il  a single  memory  chip  contains 
more  than  one  hit  of  a word,  there  is  the 
possibility  of  multiple  hit  errors.  The  recom- 
mended approach  for  DP/M  memory  is  the  use 
of  a single  parity  hit  per  word.  It  is  also 
possible  to  check  to  see  if  the  correct  word  has 
been  accessed  as  well  as  to  see  if  the  data  is 
correct.  This  can  he  done  by  storing  the 
"address  parity"  along  with  the  data,  further, 
it  is  possible  to  combine  the  address  and  the 
data  parity  into  a single  address-data  parity  hit. 
and  this  parity  technic|iie  is  recommended  lor 
the  DP/.M  memory. 

Allocation  of  Memory  Space 


figure  f>0  slurws  the  probable  memory 
address  space  allocation  for  the  DP.'M  PI..  Ihe 
processor  can  address  (>4K  words  of  memory: 
however,  only  a small  portion  (XK)  is  expected 
to  he  required  for  operational  piograms.  The  low 
address  portion  of  memory  is  reserved  for  the 
subroutine  directory  anil  interrupt  trap  vector 
locations,  fable  14  lists  the  likely  allocation  of 
memory  locations  for  the  PI  interrupt  trap 
vectors.  A lecommc.ided  use  of  high  address 


PE  MEMORY  ALLOCATION 


? 

RESERVED 


UNUSED 


READ/WRITE 


READ  ONLY 
(PROTECTED 
OR  ROM) 


Figure  <>0.  1*1:  Memory  Allocation 


TABLE  14  PE  INTERRUPT 
VECTOR  SPACE  ASSIGNMENTS 


Location 

(HEX)  Assignment 


OOOO 

oau 

Reserved  tor  diagnostics 

ax>: 

000 1 

ITiaxsigued 

0004 

000s 

Invalid  instruction 

0006 

000’ 

Overtlow 

ooos 

ooar 

Device  acknowledge  error 

000 A 

O00B 

Memory  emu  reserved 

oooc 

OCOI) 

Interrupt  0 

oool 

OOOf 

imeiiupi  1 

0010 

(Kill 

Interrupt  2 

oot : 

0015 

Inlet  nipt  3 

0014 

001? 

Interrupt  4 

001 « 

oo  r 

Intel  lupi  ? 

001  s 

0014 

Intel tupt  6 

001  A 

auB 

Intel  rupt  ’ 

OOIC 

ami 

Interrupt  6 

0011 

00  IF 

Interrupt 11 

Figure  61.  DP/M  PE  Sub-element 


memor>  is  tor  the  location  of  maintenance  function  sottware.  Subsection  IV.L  describes  how 
these  high  order  memory  locations  can  be  used  for  such  functions  as  programmer  maintenance 
panel  routines  or  aerospace  ground  equipment  i.AGF)  maintenance  functions. 

D.  PE  INTERNAL  INTERCONNECTION 

The  tour  sub-elements  of  the  DP  M PI  (shown  in  Figure  61 1 require  a method  of  interface 
lor  i n ter- PI  communication.  The  PF  internal  interconnection  must  provide  facilities  for  data, 
address,  and  various  control,  status,  and  clock  signals.  This  requires  cither  several  sets  of  lines,  or 
the  tune-multiplexing  ol  several  of  these  onto  a single  set  of  lines.  Multiplexing  decreases  the 
number  ot  lines  but  at  the  expense  of  some  increase  in  chip  complexity  and  a corresponding 
decrease  in  PI  perlormance.  'Iliux.  the  use  of  separate  address,  data  and  control  lines  in  the  PF  is 
recommended.  I he  alternative  is  to  time-multiplex  the  address  and  data  over  the  same  lines  while 
keeping  the  control  lines  separate.  To  maintain  an  adequate  performance  level  and  to  simplify 
the  mtra-PI  control,  the  DP  M PI  will  use  separate  address,  data,  and  control  lines. 

To  minimi/e  the  number  ot  pins  required  on  the  PF  sub-elements,  a simple  internal 
address  and  data  hus  (l-Bl'S)  structure  has  been  used.  One  of  these  control  signals  is  used  to 
specity  whether  a memory  or  an  I O transfer  is  in  progress,  thus  permitting  the  same  set  of  lines 
to  serve  tor  both  I ()  and  memory  transfers.  Additional  control  lines  allow  several  different  users 
to  share  the  l-Bl.’S  and  the  use  ot  mtra-PI  functional  modules  having  different  speeds  to  operate 
with  l-BIS  users.  ( ontrol  lines  are  provided  in  association  with  the  interrupt,  maintenance,  and 
memory  control  (unctions.  Details  ot  the  l-BL'S  are  given  in  the  l-BUS  specification  and  the 
FBI’S  signals  are  summarized  in  Tahle  15.  Although  there  are  80  pins  (20  are  power  and  ground) 
defined  tor  the  interlace  to  the  bus.  only  a limited  number  are  used  by  an  particular  device.  For 
example,  the  processor  requires  an  interface  with  only  48  of  the  80  pins. 


TABLE  IS.  PROCESSING  ELEMENT  INTERNAL  BUS  (I-BUS)  SIGNALS 


Processor 

Function 

Mnemonic 

I-BUS* 

Module 

Data 

DATA 

16 

16 

Address 

ADDR 

16 

16 

Data  and 

Transfer 

Control 

UO  Select 
Dat..  Receive 

IOSL 

DRCL’ 

1 

1 

1 

1 

Tran  fer  Request 

TRQ 

1 

1 

Transfer  Acknowledge 

TACK 

1 

1 

Transfer  Time  Out 

TTO 

1 

1 

Transfer  Abort 

TABT 

1 

1 

Bus  Request 

BRQ 

1 

1 

Bus 

Bus  Release 

BRF.L 

1 

1 

Master 

Bus  Gran*.  In 

BGRI 

1 

1 

( trol 

Bus  Grant  Out 

BGRO 

1 

Bus  Master  ID 

BMID 

4 

Interrupt  Request 

IRQ 

1 

1 

Interrupt 

Interrupt  Inhibit 

INIIB 

1 

- 

Control 

Interrupt  Acknowledge  In 

IAKI 

1 

Interrupt  Acknowledge  Out 

IAKO 

1 

1 

Free-Running  Clock 

FCLK 

1 

- 

General 

Master  Clock 

MCLK 

1 

1 

Bus 

Master  Stop 

MSTP 

1 

- 

Facilities 

Clear  Reset 
Power  'Ground 

CLR 

1 

20* 

1 

-> 

Processor  Status 

PSTAT 

1 

1 

Special 

Memory  Parity 

MPAR 

1 

F .notions 

Memory  Write  Inhibit 

MWI 

1 

Special  Functions  Line 

SFL 

3 

HO  48 


•Normally  I-BUS  signals  are  distributed  as  "low  true." 

♦Lor  proper  power  distribution  and  signal  ground  returns,  there  are  multiple  power  and 
grou.i  pins.  In  addition,  all  the  standard  supply  voltages  shall  be  provided  to  allow 
mi.Mt  v of  different  technologies 


A major  advantage  of  this  1-BUS  structure  is  the  flexibility  that  it  provides.  The  1-BUS  is 
simply  a set  of  signal  lines  with  a standardized  interface  specification.  This  standard  interface 
allows  the  use  of  a wide  range  of  different  functional  modules  as  well  as  permitting  the 
upgrading  of  the  system  as  newer  technologies  evolve.  Figure  62  shows  how  the  processor 
sub-elements  may  now  be  built  using  current  low-power  Schottky  TTL  devices  on  three  small 
pnnted-circuit  cards.  One  card  would  contain  the  control  and  the  two  others  would  be  byte 
(8-bit(  slices  of  the  data  processor  portion  of  the  processor.  As  more  complex  MSI  and  LSI  chips 
become  available,  the  data  portion  could  be  reduced  to  a single  card.  Similar  situations  exist  for 
the  memory.  I/O.  and  BIU.  The  1-BUS  structure  permits  the  DP'M  PL  to  be  built  with  present 
technology,  and  provides  for  integrating  new  implementations  of  PL  sub-elements  with  minimum 
impact  on  existing  modules. 

A short  review  of  the  general  capabilities  of  the  I-BUS  will  serve  to  illustrate  its  flexibility. 
The  I-BUS  characteristics  can  be  divided  into  the  data  and  transfer  control,  bus  master  control, 
interrupt  control,  general  bus  facilities,  and  special  functions. 


DP  /M  MODULES 


. DP/M  Modules 


1. 


Data  Transfer  and  Control 


Data  transfers  on  the  I-BUS  are  effected  as  a demand/response  sequence  between  a bus 
master  (such  as  the  processor)  and  a bus  slave  (such  as  a memory  or  an  I/O  device).  Figure  63 
shows  data  being  sent  from  a master  to  a slave.  This  activity  is  initiated  by  the  master  via  the 
transfer  request  (TRQ)  line.  The  slave  identifies  t h ;■ ' it  has  been  specified  by  decoding  the 
address  and  1'0-select  lines.  When  the  slave  has  completed  its  decode  process  and  recorded  the 
data,  it  responds  by  asserting  transfer  acknowledge  (TACK).  When  the  master  receives  the 
acknowledge,  it  completes  its  part  of  the  cycle  by  terminating  its  transfer  request  and  releasing 
the  data,  address,  and  I O select  lines.  The  slave  completes  its  part  of  the  transfer  by  terminating 
its  transfer  acknowledge  when  it  sees  the  transfer  request  end. 

figure  (>4  shows  data  being  received  by  a master  from  a slave.  This  sequence  is  similar  to 
the  send  sequence  except  the  slave  places  the  information  onto  the  data  lines  and  then  asserts 
transfer  acknowledge.  When  the  master  has  received  the  data  and  latched  it  into  a register,  it 
terminates  the  transfer  by  dropping  the  transfer  request  line  and  releasing  the  address  and  I/O 
select  lines.  The  slave  then  releases  the  data  lines  and  drops  its  transfer  acknowledge  signals. 

In  addition  to  this  normal  transfer  request  acknowledge  sequence,  there  are  two  ways  in 
which  a transfer  can  be  terminated  abnormally.  I he  first  is  with  the  transter  time  out  line  (TTO) 
which  is  generated  by  a watchdog  timer  on  the  memory  control  chip.  This  time  out  is  used  to 
prevent  a master  device  from  locking  up  the  l-BUS  by  attempting  to  address  either  nonexistent 
memory  or  10  devices.  When  the  time  out  occurs,  the  master  uses  the  time  out  signal  in  the 
same  manner  as  a transfer  acknowledge  signal,  except  it  sets  its  own  time  out  error  flag,  and 
proceeds.  In  the  case  of  the  processor,  this  will  correspond  to  either  an  I/O  acknowledge  time 
out  or  a memory  error.  The  second  abnormal  transfer  termination  is  the  transfer  abort  (TABT). 
This  line  is  used  in  conjunction  fth  the  bus  release  (BREL)  by  a higher  priority  master  to  force 
a lower  priority  bus  master  to  relinquish  control  of  the  bus.  When  this  occurs,  the  lower  priority 
bus  master  formerly  in  control  simply  continues  from  the  point  it  was  when  it  regains  control  of 
the  bus.  The  only  effect  this  has  on  the  pre-empted  bus  master  is  that  its  transfer  appears 
(without  time  out)  to  take  longer  than  normal.  These  “handshaking”  sequences  for  transfers 
ensure  that  the  data  has  been  correctly  transferred  independent  of  the  speed  of  either  the  master 
or  the  slave  device.  This  allows  mixing  of  technologies  for  memories,  processor.  UO,  and  BIU. 

2.  I-BUS  Master  Control 

There  are  thre»  control  lines  and  a set  of  four  identification  lines  associated  with  bus 
master  control  (Figure  65).  These  three  control  lines  are  used  to  control  the  assignment  of  the 
bus  to  a bus  master.  The  assignment  is  performed  on  a first-eome-first-serve  basis,  with  hardwired 
priority  used  to  resolve  simultaneous  requests.  1 ne  four  identification  lines  are  associated  with 
the  maintenance  function.  The  master  that  is  in  control  of  the  bus  places  its  identification  code 
on  these  lines  (processor  = 0:  the  II)  default  value).  This  identification  is  especially  useful  during 
the  “address  breakpoint”  maintenance  function  where  it  is  important  to  be  able  to  identify  who 
issued  the  breakpoint  address.  The  use  of  four  lines  allows  the  unique  identification  of  up  to  15 
bus  masters  in  addition  to  the  processor. 

The  three  bus  master  control  signals  are  bus  request  (BRQ).  bus  release  (BREL),  and  bus 
grant  (B(>R).  The  bus  request  line  is  used  to  initiate  a bus  master  assignment,  while  the  bus 
release  line  is  used  to  terminate  the  assignment.  The  bus  grant  line  is  threaded  through  each 


Figure  63.  1-Bus  Master  to  Slave  (Memory-1/0)  Send  Cycle  (Delay  is  Exaggerated  for  Clarity) 


AT  MASTER 


Figure  65.  I -Bus  Muster  Device  Interconnect, .'n 


modulo  .mil  is  used  to  resolve  conflicts  when  two  or  more  masters  request  a bus  simultaneously. 

I igurc  no  shows  a representative  bus-assignment  sequence.  When  the  bus  quiescent  master  “A" 
requests  the  Inis  by  asserting  bus  request  line,  no  other  master  may  request  the  bus.  When  the 
bus  request  line  is  asserted,  the  bus  grant  signal  starts  propagating  through  the  modules  on  the 
i-Bl'S  When  the  signal  reaches  the  highest  priority  requesting  module,  it  activates  that  bus 
master,  which  blocks  the  bus  grant  signal  trom  propagating  to  any  lower  priority  module  which 
may  also  be  requesting  the  bus.  At  this  point,  the  bus  master  (which  has  been  selected)  places  its 
identil nation  on  the  bus  master  ID  lines  (BMID)  and  starts  transterring.  When  it  starts  its  last 
transter  (depicted  by  the  X-X  vertical  line)  it  issues  a bus  release.  This  command  forces  all  bus 
ters  including  itsell  to  remove  their  bus  requests.  As  soon  as  the  bus  requestts)  have  been 
removed,  bus  release  is  also  removed.  When  the  bus  release  has  been  removed,  any  master  can 
request  the  bus  by  requesting  the  bus  request  line.  Again,  the  bus  grant  signal  will  propagate  to 
the  highest-pnonty  requesting  bus  master.  This  new  bus  master  will  wait  until  the  bus  is 
quiescent  (transfer  request  and  transter  acknowledge  have  ended)  and  start  its  transfer  eyelets), 
fins  sequence  allows  bus  mastership  resolving  to  be  overlapped  with  the  data  transfers,  thus 
minimizing  or  partially  eliminating  the  overhead  associated  with  bus  mastership  assignment.  As 
was  noted  under  the  data  transfer  discussion,  a higher-priority  bus  master  can  force  a lower- 
prionty  master  oil  the  bus  by  pulling  on  the  bus  release  line  which  will  force  all  bus  masters  to 
release  the  Inis  and  remove  their  bus  requests. 

3.  I-BL'S  Inteirupt  Control 

There  are  three  l-BL'S  control  lines  associated  with  interrupt  control.  They  are  interrupt 
request  (IRQ),  interrupt  inhibit  (IN'HB)  and  interrupt  acknowledge  (IAK).  Interrupts  are  serviced 
on  a tirst-come-tirst-serve  basis  with  priority  resolution  it  there  are  simultaneous  interrupts.  The 
interrupt  request  is  issued  by  any  device  that  wishes  to  interrupt  the  processor  (Figure  67).  There 
may  or  may  not  be  ..n  interrupt  mask  associated  with  (and  internal  to)  the  device  which  will 
inhibit  the  device  trom  issuing  an  interrupt  request.  In  addition,  there  is  an  interrupt  inhibit  line 
which  is  used  by  the  maintenance  panel  to  inhibit  all  devices  trom  interrupting  the  processor 
when  it  is  operating  in  the  maintenance  panel  mode.  When  the  processor  xmpletes  the 
execution  of  the  current  instruction,  it  honors  any  interrupt  by  asserting  interrupt  acknowledge. 
The  inteirupt  acknowledge  line  is  threaded  through  all  modules  and  activates  the  highest-priority 
interrupting  device.  Ibis  device  inhibits  the  interrupt  acknowledge  (IAK)  signal  trom  propagating 
to  lower-prioritv  modules.  \Uien  the  device  receives  its  interrupt  acknowledge.-  it  places  the 
address  of  its  memory  interrupt  trap  vector  location  onto  the  data  lines.  It  then  indicates  that  it 
has  placed  this  address  or  the  lines  by  asserting  transfer  acknowledge  The  processor  latches  the 
address  into  it-  internal  register  and  completes  the  cycle  by  removing  the  interrupt  acknowledge 
The  device  will  then  remove  its  interrupt  request  when  it  averts  truster  request  and  removes  the 
address  trom  the  data  lines  and  terminates  its  tiaiisler  acknowledge  when  the  interrupt 
acknowledge  ends. 

4.  General  I (’L'S  Facilities  and  Special  Functions 


The  genera!  bus  taeihties  are  composed  ot  a tree-running  clock  (FC  LK).  a master  (MCLK). 
a master  stop  < MS  I Pi.  a dear  reset  fC'LR)  signal,  power  and  ground.  The  tree-running  clock 
(IT  LKl  can  he  us-'d  by  any  device  that  needs  a clock  signal.  !t  does  not  necessarily  have  any 
particular  liming  ieiationship  with  respect  to  any  of  the  other  bus  signals.  The  master  clock  is 
similar  to  'he  t.ee-runnmg  clock  except  that  it  is  controlled  by  the  master  stop  signal  while  the 
tree-running  clock  is  not  In  general,  the  tree-running  dock  will  be  used  by  slave  devices,  while 
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Figure  67.  Interrupt  Interface  Sequence 


E.  MAINTENANCE  DESIGN  CONSIDERATIONS 


One  phase  of  the  DP'M  design  effort  examined  the  impact  of  the  likely  maintenance 
functions  to  be  required  of  the  PI:  in  its  role  as  an  avionics  processing  unit  I his  examination 
included  both  the  hardware-  and  software-related  aspects  of  maintenance  I he  following 
subsections  discuss  the  key  points  identified  for  PI  hardware  check-out.  built-in-test  (Bill 
concepts,  and  a programmer  maintenance  panel  interface  concept. 

1 . Pt  Hardware  Checkout 

Since  the  processor  portion  of  the  PI-  is  likely  to  be  a single  LSI  chip,  or  possibly  a few 
devices,  there  is  little  point  in  attempting  to  isolate  hardware  faults  below  the  major  PI 
sub-element  (Processor.  Memory.  BILL  and  I Ok  Thus,  for  hardware  checkout,  it  would  be 
adequate  to  provide  a maintenance  capability  which  is  based  upon  a PI  memory  and  I O 
extension  and  use  a single  go  no-go  BIT  software  program.  I he  following  approach  is  proposed. 
The  processor  can  be  tested  by  initiating  an  interrupt  that  causes  the  processor  to  execute  its 
BIT  diagnostic  program.  If  the  processor  is  operating  correctly,  it  will  execute  its  program  and 
send  a "status  good"  complete  signal  back.  If  the  processor  has  failed,  the  signal  will  not  be  sent, 
thus  indicating  that  it  has  failed.  Once  the  processor  has  shown  that  it  is  operating  correctly,  it 
can  be  used  in  conjunction  with  additional  test  programs  to  test  the  remaining  sub-elements 

2.  Built-In-Test  (BIT)  Concept 

The  functional  design  and  architecture  of  the  PI  allows  the  system  user  a choice  as  to  the 
level  ot  BIT  to  be  used.  This  section  highlights  one  approach  to  BIT  go  no-go  testing.  The  key 
features  of  this  BIT  approach  are 

Control  of  the  internal  bus  memory  address  and  interrupt  line  to  force  the  processor 
to  execute  a BIT  software  routine 

A small  and  thorough  software  BIT  diagnostic  routine  that  performs  processor  and 
memory  self-test 

Minimum  external  control  circuitry  that  is  required  to  initiate  and  monitor  the  BIT 
results. 

This  BIT  approach  has  an  added  advantage  in  that  the  same  testing  philosophy  can  be  used 
tor  ‘light-line,  in-tlight.  and  ACd  diagnostic  environments. 

The  key  to  this  testing  philosophy  is  the  common  internal  bus  (l-BUS I that  interconnects 
the  PI  sub-elements  and  allows  data  transfers  between  memory,  processor,  and  input  output 
devices.  By  proper  control  ot  the  memory  address  and  interrupt  lines,  the  processing  unit  can  be 
directed  to  execute  the  Bll  soltware  routine  in  the  same  manner  as  a normal  interrupt  routine 
Manipulation  of  these  l-BUS  control  lines  can  be  via  external  ACiI  circuitry  through  an  ACil 
connector  on  the  PI  or  by  similar  circuitry  within  the  PI  . Previous  applications  ot  this  BIT 
concept  used  a special  operator  (pilot)  control  line  to  initiate  the  BIT  The  choice  ot 
implementation  and  degree  ot  sophistication  is  an  option  ot  the  system  designer. 

When  tlie  PI  starts  execution  ot  its  BIT  routine,  a watch  dog  timer  can  be  used  to  verity 
that  execution  ot  life  BIT  is  within  allowable  tune  limits.  It.  m the  course  of  running  diagnostic 
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E.  MAINTENANCE  DESIGN  CONSIDERATIONS 


One  phase  of  the  DP  M design  effort  examined  the  impact  of  the  hkelx  maintenance 
functions  to  be  required  of  the  PI:  in  its  role  as  an  avionics  processing  unit  I his  examination 
included  both  the  hardware-  and  software-related  aspects  of  maintenance  I lie  following 
subsections  discuss  the  key  points  identified  for  PI  hardware  check-out.  built-m-tesl  < BIT  ) 
concepts,  and  a programmer  maintenance  panel  interface  concept 

1 . Pt  Hardware  Checkout 

Since  the  processor  portion  of  the  PI  is  likely  to  be  a single  LSI  chip,  or  possibly  a few 
devices,  there  is  little  point  in  attempting  to  isolate  hardware  faults  below  the  inaior  PI 
sub-element  (Processor.  Memory.  Bll!.  and  I O).  Thus,  for  hardware  checkout,  it  would  be 
adequate  to  provide  a maintenance  capability  which  is  based  upon  a PL  memory  and  I O 
extension  and  use  a single  go  no-go  BIT  software  program.  I he  following  approach  is  proposed. 
The  processor  can  be  tested  by  initiating  an  interrupt  that  causes  the  processor  to  execute  its 
BIT  diagnostic  program.  If  the  processor  is  operating  correctly,  it  will  execute  its  program  and 
send  a “status  good"  complete  signal  back.  If  the  processor  has  failed,  the  signal  will  not  be  sent, 
thus  indicating  that  it  has  failed.  Once  the  processor  has  shown  that  it  is  operating  correctly,  it 
can  be  used  in  conjunction  with  additional  test  programs  to  test  the  remaining  sub-elements. 

2.  Built-In-Test  (BIT)  Concept 

The  functional  design  and  architecture  of  the  PI  allows  the  system  user  a choice  as  to  the 
level  of  BIT  to  be  used.  This  section  highlights  one  approach  to  BIT  go  no-go  testing.  The  key- 
features  of  this  BIT  approach  are 

Control  of  the  internal  bus  memory  address  and  interrupt  line  to  force  the  processor 
to  execute  a BIT  software  routine 

A small  and  thorough  software  BIT  diagnostic  routine  that  performs  processor  and 
memory  self-test 

Minimum  external  control  circuitry  that  is  required  to  initiate  and  monitor  the  BIT 
results. 

This  BIT  approach  has  an  jdded  advantage  in  that  the  same  testing  philosophy  can  be  used 
for  'light-line,  in-tlight.  and  A(il  diagnostic  environments. 

The  key  to  this  testing  philosophy  is  the  common  internal  busil-BL'Sl  that  interconnects 
the  PI  sub-elements  and  allows  data  transfers  between  memory,  processor,  and  input  output 
devices.  By  proper  control  ot  the  memory  address  and  interrupt  lines,  the  processing  unit  can  be 
directed  to  execute  the  BIT  software  routine  in  the  same  manner  as  a normal  interrupt  routine. 
Manipulation  of  these  Mil'S  control  lines  can  be  via  external  ACI  circuitry  through  an  ACil 
connector  on  the  PI  or  by  similar  circuitry  within  the  PI  . Previous  applications  of  this  BIT 
concept  used  a special  operator  (pilot)  control  line  to  initiate  the  BIT  The  choice  ot 
implementation  and  degree  of  sophistication  is  an  option  ol  the  system  designer. 

When  tile  PI  starts  execution  ot  its  BIT  routine,  a watch  dog  timer  can  be  used  to  verily 
that  execution  ol  the  BIT  is  within  allowable  tune  limits  It.  m the  course  of  running  diagnostic 
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Figure  69.  Programmer  Maintenance  Panel 


lest'  on  the  processor  and  memory.  an  emu  is  detected,  an  appropriate  signal  will  he  genei.ited 
to  the  external  HI  I control  circuitry,  or  the  watch  dog  tmici  can  he  allowed  to  tun  to 
completion,  sigiutying  a HU -tail  condition. 

i.  Programmer  Maintenaiiee  Panel  Interface 

A necessary  part  of  the  use  of  any  system  sinnlai  to  DP  M is  heiKh-level  checkout  ol  the 
operational  software  Normal  means  of  bench-level  checkout  an-  provided  In  ptogrammei 
maintenance  consoles  or  panels.  Often  this  special  test  ctpupmciit  provides  limited  visibility  into 
the  execution  of  programs  and  displays  results  of  hardwaie  and  software  activities  via  bmaiy  or 
hex  data  read-out  lights  Input  data  to  the  maintenance  panel  likewise  is  oltcn  via  toggle  01 
rotary  dial  switches.  One  result  ot  the  DP  M PI.  design  was  the  identification  ol  a flexible 
programmer  maintenance  interface  that  required  minimum  external  hardware  and  provided  a 
convenient  and  adaptable  method  ot  loading  and  monitoring  the  execution  of  PI.  programs. 

I he  proposed  programmer  maintenance  panel  consists  ot  a set  ol  hex  1.11)  displays, 
hexidecimal  data  entry  keyboard,  mode  control  pushbuttons,  diagnostic  invoking  pushbuttons, 
and  a series  of  programmer  read  modify  write  I unction  keys.  The  maintenance  panel  can  also 
provide  a standard  teletype  interface,  figure  h‘>  shows  the  maintenance  panel  organization. 
Representative  software  r « . i » i v provided  in  the  maintenance  panel  would  be: 

Program  start  >d  stop 

key  board  control 

Display  control 

( (inversion  routines  Binary  to  Ilex.  Hex  to  Binary..  Binary  to  Decimal,  etc. 

Memory  inspect  and  change 
Register  inspect  and  change 

* 

Breakpoint  control 
Teletype  control 

Program  load  and  memory  register  tile  content  display  to.  a haid  copy  pimtct  device. 

The  purpose  ot  the  maintenance  panel  is  to  facilitate  system,  suh-s\ stem,  haidvvaie.  and 
sotlware  checkout  Its  functions  are  composed  ot  processor  and  memory  hardware  diagnostics, 
program  execution  display  and  control  features,  and  a memory  address  or  I O ( oinmaiid  Nddicss 
Word  breakpoint  Ml  ot  these  functions,  with  the  exception  ot  the  bieakpoint.  use  the  procc'ssoi 
itsell  to  pertornt  the  iicic-ssaiy  operations  Ibis  ..u>  be  accomplished  In  ptoviding  the 
inamlenaiue  panel  with  suitable  inleimpi  and  I O capability  along  witii  iis  own  dedicated 
section  ol  memoiy  f h is  section  ot  maintenance  mcinoiy  contains  t lie  iKcessaiy  progi.nn  and 
data  storage  to  implement  the  desired  mamteiiaiue  paiul  opciatioiis  \ discussion  <>t  likely 
operation  <>l  t h is  mamlen.iiue  panel  concept  follows 

Pressing  the  “Slop"  or  anv  ol  the  olliei  lesl  keys  on  ihc  panel  will  cause  the  appiopnate 
interrupt  to  be  generated  Whenever  one  ol  the  m.unienance  Iuik  lions  is  initiated,  the  an  lent 
St  ite  «>t  processor  execution  is  saved  I Ills  slate  is  lestoud  and  execution  lesiimed  at  the 
completion  'll  t Ik  parliciil.u  luiMioii  I urt lie  r . while  am  ol  these  tun.  lions  ot  Bieakpoint  Slop 
jre  in  progress  all  noil  maintenance  panel  mleiinpls  .ne  inlnhiled  via  the  INHB  control  line  ol 
the  internal  bus  I mu  lions  allowable  with  this  maintenance  panel  ntUil.uc  in.  hide 


1 1 jr  J ware  diagnostics  including  processor  BIT.  memory  check-sum,  and  read/write 
tests 

Program  execution  display  in  a user-defined  format  (hex.  octal,  decimal) 

Program  execution  control  to  include  instruction  step,  memory  address  breakpoint. 
1C)  command  address  breakpoint,  and  internal  bus  step 

Program  modification  to  include  memory  and  register  content  read/modify 
operations 

Programmable  interface  to  a memory  load  device  such  as  a paper  tape  reader  or 
magnetic  tape  cassette  or  a hard  copy  printing  device. 

F.  PROCESSOR/MEMORY  DESIGN  SUMMARY 

This  section  has  described  the  DP'M  processor,  memory.  PF  internal  bus.  and  presented  a 
possible  maintenance  panel  interface  concept.  It  has  described  their  functional  and  physical 
characteristics.  Various  tradeoffs  have  been  made  and  a final  DP’M  baseline  design  presented. 
This  effort  included  both  a top  level  as  well  as  detailed  analysis.  The  internal  bus  (l-BUS) 
structure,  one  of  the  most  important  features  of  the  DP'M  architecture,  has  been  defined  and 
described.  By  defining  a standard  bus  and  its  interface  characteristics  the  PI:  architecture  is  given 
considerable  flexibility  and  growth  capabilities.  This  allows  an  orderly  growth  and  evolution  of 
the  DP  M PI  as  new  technologies  evolve  and  mature,  and  as  requirements  change.  One  of  the 
applications  of  this  flexibility  is  the  implementation  of  a simple  but  powerful  maintenance  and 
AGI  interface  that  takes  advantage  of  the  processor  tor  execution  of  test  function  and  requires 
minimal  external  memory  and  I ()  circuitry  This  concept  allows  the  maintenance/AGfc  function 
to  be  much  more  flexible  and  lower  iost  than  normally  would  be  possible  with  the  use  of  unique 
special  tesi  equipment. 
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SECTION  V 

EXTERNAL  DEVICE  COMMUNICATIONS  INTERFACE 


A.  SYSTEM  INPUT/OUTPUT  APPROACH 

The  DP  M sy stem  approach  to  providing  a communications  interlace  between  the  !)P/M 
s>stem  and  the  vanous  external  aircraft  subsystem  equipments  is  directly  via  the  individual  DP/M 
Processing  hlements  <PLs>.  as  shown  in  Figure  70.  Thus,  all  external  (I/O)  device  data  can  be 
introduced  within  the  DP/M  system  by  being  “relayed”  through  the  individual  system  PF.s.  This 
approach,  in  effect,  dedic;  tes  devices  to  PI  s but  simplifies  system  bus  interface  requirements  and 
system  hardware  overhead.  The  method  of  interlace  chosen  is  a straightforward  parallel  digital 
interface  with  external  devices.  PF  access  to  multiple  devices  or  multiple  PF.  access  to  common 
devices  must  be  accomplished  externally  to  the  DP  M system  hardware  (i.e..all  multiplexing 
(unctions  required  must  be  provided  by  external  hardware  interlaces). 

The  primary  advantages  of  this  basic  approach  are  reduced  system  hardware  complexity 
and  simplified  system  operation.  No  special  bus  interface  hardware  >s  required  tor  I/O  devices 
and  I/O  device  activities  can  be  placed  under  the  direct  flexible  control  of  user  programs  resident 
in  the  Pt  to  which  the  devicets)  is  connected. 

Intuitive  disadvantages  associated  with  this  approach  were  concerned  with  system 
reliability  or  fault  tolerance  owing  to  the  “dedication”  of  PI;s  to  I/O  devices  and  the  potential 
increase  in  Global  bus  traffic  resulting  from  the  distribution  of  multiple-user  I O data.  These 
initial  concerns  were  adequately  quashed,  with  the  following  realizations: 

With  respect  to  overall  system  reliability,  an  LSI  DP'M  PL  will  possess  comparable 
hardware  operational  reliability  to  that  of  a specialized  bus  interface  for  the 
external  device  (assuming  an  10  distribution  bus  system  approach).  The 
reliability  ol  the  device  interface,  specifically  the  DP'M  PF,  is  inherently  much 
greater  (perhaps  by  several  orders  ol  magnitude)  than  the  majority  of  avionics 
devices  to  which  it  must  interface.  Bolstering  the  reliability  of  the  device 
would  be  a fallacious  attempt  at  improving  overall  system  reliability.  This 
alternate  approach  becomes  even  more  impractical  when  its  implications  on 
added  hardware  complexity  are  considered.  It  is  recommended  that  improved 
system  IO  reliability  be  accomplished  in  the  external  equipment  (e.g.,via 
redundant  devices)  where  critical  reliability  requirements  prevail. 

With  respect  to  potential  Globa!  bus  traffic  increase  resulting  from  the  distribution 
of  interfunctional  data,  it  was  recognized  that  most  1 'O  device  data  tends  to 
be  unifunctional  in  usage,  i.e  . most  I/O  data  is  functionally  unique  and  used 
exclusively  by  a single  (unction.  The  bulk  of  I O data  whiin  is  distributed 
to  from  the  device  interfacing  PF  can  be  localized  and  routed  via  the  Local 
bus  links  within  the  affinity  group  users  of  the  device  data.  Globa!  traffic 
increases  are  expected  to  be  insignificant,  with  primary  bus  traffic  loading 
occurring  on  the  Local  buses  of  the  "host"  affinity  group  where  it  is  most 
easily  accommodated  in  terms  of  bus  bandwidth  consumption  with  minimum 
effect  on  overall  system  performance 
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In  the  chosen  system  approach,  the  PI  can  assume  tl  e system  roles  of  an  external  device 
interface,  an  external  device  data  preprocessor,  or  a distributed  member  of  a "centralized*’ 
processing  function.  A PI-  cat:  assume  any  or  a'l  of  the  above  roles,  depending  on  system 
requirements.  Topological  and  functional  identity  boundaries  are  not  necessarily  fixed  with 
respect  to  each  other:  they  may  or  may  not  coincide  in  a particular  application. 

B.  INPUT/OUTPUT  INTERFACE  FUNCTIONAL  REQUIREMENTS 

Having  decided  upon  the  aforementioned  system-level  approach  to  interfacing  the  DP'M 
PE  with  external  devices,  an  analysis  of  the  actual  functional  requirements  imposed  by  the 
envisioned  DP  M system  I/O  environment  was  performed.  In  the  course  of  arriving  at  a “most 
desirable”  PE-to-external  device  interface  design  the  following  basic  concepts  were  considered  to 
be  of  rudimentary'  importance  in  molding  the  des'gn. 

1.  Standardized  Digital  Device  Interface  Compa  ibility 

A “standardized”  interface  compatibility  concept  ranks  first  and  foremost  as  an 
input, Output  Interface  Unit  (I01U)  design  goal.  Since  definition  of  a preliminary  standard 
interlace  for  aircraft  equipments  and  TDM  data  bus  systems  is  being  developed  by  the  Air  Force 
for  future  avionics  applications,  the  desire  to  conform  DP/M  concepts  within  this  standardization 
framework  is  intuitively  obvious.  The  subject  Air  Force  standardization  approach  is  presently 
governed  by  MIL-STD-1 553.  “Military  Standard  for  Aircraft  Internal  Time-Division  Multiplex 
Data  Bus."  The  subject  standard  external  device  interface  is  defined  for  the  Subsystem  Interface 
Unit  (SSIU)  vi  ich  interfaces  various  unique  aircraft  sensors/effectors  with  a serial  TDM  data  bus 
interlace  unit  referred  to  as  a Multiplex  Terminal  Unit  (MTU). 

It  is  believed  that  an  avionic  equipment  standardization  approach  sought  by  the  Air  Force, 
as  reflected  in  MIL-STD-1 553,  is  a viable  and  imminent  solution  to  many  present  avionic  system 
ailments.  Therefore,  it  has  been  previously  proposed  that  the  DP/M  I/O  interface  be  compatible 
with  the  SS1U  specification.  However,  such  an  interface  has  not  been  firmly  specified/defined 
and  the  chance  for  it  assuming  a “special-purpose”  configuration,  tuned  to  the  requirements  of 
the  MTU  to  which  it  interfaces,  are  perhaps  great.  It  may  be  argued  that  such  an  interface 
should  be  driven  by  “general-purpose”  requirements  to  allow  compatibility  with  a large  number 
of  alternative  avionic  information  processing  system  elements,  one  of  which  is  the  DP/M  PE.  It 
also  seems  rational  and  feasible  to  develop  the  DP/M  input/output  interface  capability  around  a 
similar  set  of  goals  to  allow  maximum  compatibility  with  a variety  of  equipments  The  interface 
design  described  herein  reflects  this  goal.  Furthermore,  it  is  recommended  that  the  present  SSIU 
interlace  definition  be  modified  and  driven  by  the  same  interface  philosophy  if  true  aircraft 
system  flexibility  is  to  be  achieved  in  the  future  (e  g.,  asynchronous  instead  of  synchronous  data 
isfer  protocol). 

2.  Data  Rate  Requirements 

The  actual  performance  potential  requirement  placed  on  the  10  interface  in  terms  of  data 
throughput  has  been  initially  established  by  analyzing  the  I/O  traffic  experienced  in  the  baseline 
system  mission  processing  functions.  The  results  of  this  analysis  have  shown  that  total  system 
I ()  i external  device)  tratfic  is  7(>2.400  kilobits/second.  The  worst-case  maximum  for  a given 
(unction  is  522.1  MJ  Kbps,  this  corresponds  to  the  worst-case1  requirement  possible  for  a single 
PI ...  assuming  a single  PI  were  assigned  to  the  interfacing  of  all  function-  elated  equipments.  This 
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worst-case  data  rate  ot  522. lot)  Kbps  is  roughly  equivalent  to  a word-trail ic-rate  ol  32.(i35 
I O-bit  words  second  Thus.  the  bandwidth  requirements  ot  the  avionic  system  application 
envisioned  do  not  impose  a severe  requirement  on  the  throughput  capabilities  ol  the  I/O 
interlace  from  an  implementation  viewpoint. 

3.  Program  Interference 

An>  I O responsibility  associated  with  a processing  (unction  must  be  considered  in  the 
contest  of  program,  or  processing,  mterteience  caused  by  the  ! ()  data  transters.  I O data  rates 
alone  can  be  misleading  unless  f heir  ettects  on  processing  execution  time  are  considered.  The 
baseline  processing  functions  requiring  the  relatively  higher  data  rates  typically  are  associated 
with  block  transters  ot  large  amounts  ol  data  Thus,  to  alleviate  what  may  become  appreciable 
I ()  overhead  execution  time  in  the  associated  process,  it  is  considered  desirable  to  provide  an 
I O-ptocosing  overlap  capahilitv  lor  I <)  data  transfer  operations  to  reduce  processor  intervention 
in  these  operations  to  a minimum. 

4.  PL  Support  functions 

Several  existing  ancillary  tunctions  must  be  provided  within  each  Pf  to  allow  proper  ?h 
performance  in  the  1)P  M environment,  in  the  overall  Pf  design,  it  is  the  responsibility  of  the 
IOIL"  to  provide  these  tunctions.  These  various  tunctions  are  individually  discussed  below. 

a Real-Time  Reference 

Since  the  DP  M system  must  operate  m a real-time  avionics  environment,  some  accurate 
means  of  time-keeping  must  be  accessible  by  each  Pf.  Owing  to  reasons  of  system  distributive- 
ness. tault-tolerance.  and  overall  performance,  it  was  decided  to  incorporate  a programmable 
"tune-tick*'  mechanism  in  each  Pf..  A programmable  interval  timer  was  considered  most 
appropriate  for  this  requirement  since  it  allows  dynamic  time-keeping  resolutions,  depending  on 
individual  application  program  tuning  requirements,  as  well  as  allowing  either  ’“short” 
tune-interval  or  “time-ol-day " real-time-keeping  procedures  with  reasonable  accuracy. 

h.  RE  Initialization  Control 

Control  must  be  provided  within  each  Pf  to  provide  an  orderly  and  predictable  sequence 
ot  Pf  operations  subsequent  to  the  application  ol  regulated  IK'  power  to  the  PL  or  the 
occurrence  ol  an  externally  invoked  ('Ll  AK  Rl  SI  f signal.  This  control  pi  ices  each  PL  in  a 
known  state  which  accommodates  system  start-up  or  mitiah/ution  activities 

c.  PE  Clock  Control 

I lie  Kill  is  responsible  toi  genet  at  mg  all  docks  required  internal  to  the  PL  trom  an 
externally  provided  "tree”  clock  source  ( lock-gating  control  provides  tor  proper  tuning  ot  PL 
clock  generation  during  power-up  conditions  and  also  provides  appropriate  clock  inhibit  control 
in  resi-ons.  to  external  commands  leg.  trom  a maintenance  programmer's  control  console). 

5.  Imp!  mentation  Considerations 

( (insistent  with  overali  DP  M PI  design  goals,  the  tnnctional  design  of  the  ft)  interface 
elements  should  be  amenable  to  non-o-mplcx  I SI  implementation  with  low  tool  risk 
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semiconductor  technology.  Actual  electrical  characteristics  of  the  interface  should  abide  with  the 
requirements  of  the  standard  digital  interface  ISSII'). 

With  respect  to  the  actual  functional  characteristics  of  the  lOIU,  it  is  desirable  to  design 
the  interface  so  that  a single,  common  I/O  channel,  or  set  of  common  signal  lines,  can  be  used 
to  effect  all  modes  of  data  transfer  operations,  i.e.,  both  program  t direct  I I/O  and  direct  memory 
access  LO  modes.  This  functional  characteristic  is  of  virtue  when  I/O  signal  pin-out  requirements 
are  considered.  In  the  same  context  of  I/O  pin-out  frugality,  it  is  desirable  to  organize  the 
input/output  channel  as  a half-duplex  bidirectional  ("party  line”!  I/O  bus  configuration  since 
onlv  ilf-duplex  functional  operation  is  required:  however,  where  special  interfaces  can  dictate 
nonbu»-oriented  TO  (i.e..  separate  input  and  output  lines!,  the  functional  design  of  the  lOIU 
should  accommodate  this  design  extension,  if  practical  from  an  implementation  viewpoint. 

6.  Extended  Capability  Considerations 

If  the  DP/M  Pb  is  to  become  a true  universal  avionic  system  building  block,  its  application 
in  nontypical  DP/M-like  applications  should  not  be  precluded.  To  adapt  readily  in  this 
environment,  the  I/O  interface  should  be  as  flexible  (general-purpose)  as  possible  and  considera- 
tion should  perhaps  be  given  to  direct  PE-to-PE  (01  processor-to-processor)  communications  via 
their  I/O  interfaces.  Therefore,  it  should  be  a target  of  the  I01U  design  to  allow  such  direct 
communications  via  the  same  I/O  channel  design  as  determined  by  previous  considerations. 

C.  lOIU  FUNCTIONAL  DESIGN  DESCRIPTION 

The  lOIU  design  described  herein  is  functionally  represented  in  the  block  diagram  of 
Figure  71.  This  design  provides  the  mechanisms  necessary  to  fulfill  the  functional  requirements 
outlined  above.  The  operational  characteristics  of  each  individual  mechanism  are  discussed  below. 

1.  Standardized  Data  Transfer  Channel 

The  actual  "LO  Channel”  design  chosen  for  the  DP/M  PE  provides  a block-oriented, 
autonomously  controlled  direct  memory'  access  (DMA)  facility  for  transferring  blocks  of  data 
between  an  I O device  and  PL  memory'.  Each  block  transfer  activity  is  initiated  under  program 
control  but  then  proceeds  autonomously  until  block  completion,  at  which  time  an  interrupt 
stimulus  is  generated  to  denote  data  transfer  completion.  The  autonomous  channel  design  was 
chosen  because: 

The  SSIU  interface  inherently  requires  half-duplex,  block-oriented  data  transfers 

It  provides  an  "overlapped"  I/O  capability,  requiring  minimum  program  execution 
time  overhead 

It  does  not  significantly  impact  the  design  with  respect  to  LSI  implementation. 

This  design  meets  the  basic  I/O  interface  conceptual  design  criteria  established  from  an 
overall  system  viewpoint.  The  operation  of  each  functional  element  of  this  design  is  conventional 
in  nature  and  is  well  understood  in  operational  characteristics.  The  specific  signal  lines  appearing 
at  the  physical  interface  are  assigned  primarily  to  provide  M1L-STD-1 553  SSIU  interface 
functional  compatibility  and  versatility  while  minimizing  pin-out  requirements  for  "single-chip" 
LSI  implementation.  In  the  interest  of  application  and  usage  flexibility,  special  operational 
features  have  been  added  to  the  Data  Channel  design  to  allow  efficient  use  with  a wide  variety 
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Figure  71.  Inpul/Output  Interface  Unit  Functional  Block  Diagram 


of  external  equipments.  A chaining  operation  feature  lias  been  added  to  the  autonomous  DMA 
operation  to  lessen  program  ovemead  associated  with  managing  block  data  I/O  operations  among 
multiple  devices  and  to  facilitate  interfacing  with  multiple  data-block  oriented  devices  (e.g.. 
magnetic  recording  devices  which  may  be  used  for  in-flight  recording  equipment,  mav.  memory, 
etc.).  Tlie  added  complexity  to  the  I OIL'  hardware  was  judged  minimal  and  should  be  of  no 
significance  in  IOII 1 implementation. 

The  channel  operation  allo-vs  the  discrimination  of  special  “command”  information 
translers  from  normal  data  transfers.  Importantly,  the  transfer  ol  commands  and  data  can  be 
intermixed  in  a single,  common  data  transfer.  This  “device-controller-oriented”  feature  expenses 
data  transfer  activity  where  each  transfer  of  a block  of  data  is  preceded  by  :>n  associated 
command  to  the  device  to  be  used  in  interpretation  of  the  data.  Such  is  the  case  with  the 
standardized  SSIU  operation,  where  each  block  of  data  transferred  is  preceded  by  a control  word 
(to  the  SSIU)  indicating  the  data  transfer  activity  desired.  In  addition,  it  ’ as  determined  that 
program-synchronous  transfers  of  single  data  words  (i.e..  direct  program  controlled  I/O  via 
instruction  execution)  is  not  required  in  the  SSIU  interface  environment.  However,  the 
previously  mentioned  device  controller  oriented  design  feature  facilitates  "single-word-block” 
data  transfers  with  only  one  operation  (channel  activation).  If  actual  program-synchronous  I/O  is 
required  in  extended  applications,  these  activities  can  be  easily  accommodated  via  direct 
(buffered)  interface  with  the  PI  internal  bus  (l-bu-.t.  Thus,  the  “device-controller”  approach  was 
incorporated  with  a conventional  autonomous  DMA  input  output  operational  concept  in  arriving 
at  the  final  10  Data  Transfer  C hannel  functional  design  described  herein. 

The  external  interface  control  protocol  accommodates  asynchronous,  fully-interlocked 
transfers  for  maximum  inte.iace  generality  instead  of  the  more  specially  tailored  synchronous 
interface  defined  in  f eliminary  SSIU  vcitic.'tion  An  explanation  ot  each  interface  signal  line  :s 
presented  in  Figure  72. 

A functional  register  ievel  design  ol  the  Data  Transfer  Channel  is  shown  in  Figure  73.  The 
sequence  of  data  transfers  events  governed  by  this  interface  is  represented  in  the  flow  diagram  of 
Figure  7-t  Figure  75  depicts  the  control  word  and  data  block  structure  used  by  the  Autonomous 
Data  Transfer  Channel  during  channel  initialization  and  actual  data  transfer  procedures. 

2.  Programmable  Interval  Timer 

A Programmable  Interval  Timer  (PIT)  was  chosen  as  the  most  desirable  real-time-keeping 
device  for  the  DP  M application.  The  PIT  is  a down-counting  register  which  is  decremented  every 
50 ps.  The  PiT  is  preset  with  a desired  time  interval  tin  50-us  units)  and  initiated  under  program 
control.  The  contents  of  the  PIT  can  be  read  under  program  control  at  any  time  without 
aftecting  counter  op  ration.  At  the  completion  of  a count-down  procedure  (i.e..  when  the 
counter  value  reaches  zerol,  an  iiiteruip;  -.timulus  is  generated  to  denote  the  expiration  of  the 
time  interval  The  PIT  length  is  chosen  at  1,’  bits,  allowing  a maximum  time  interval  in  excess  of 
1.0  seconds,  thus  ottering  a good  'ompromise  between  timing  resolution  and  maximum  time 
interval  capabilities. 

3.  PL  Initialization  Contril 

Immediate  consol  ol  the  PL  subsequent  to  the  application  of  power  or  the  occurrence  of 
a ( LI  AR  RESET  command  from  an  external  source  is  manifested  ny  “steering”  the  PE  program 
execution  to  an  appropriate  memory  addre»s  for  each  initialization  event.  If  a system  power-up 
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Fijwre  73.  I/O  Data  Transfer  Channel  Register-Level  Block 
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Fi*ure  73.  I/O  Oita  Transfer  Channel  Register  Level  Block  Diagram  (Sheet  2 of  2 
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Fijwr**  75.  Autonomous  Data  Channel  Transfer  Control  Word  Format 


or  a (TEAR  RESET  stimulus  occurs.  PF  initialization  is  performed  by  first  providing  a 
PF-boot»trap  program  starting  address  to  the  processor  via  the  internal  bus  (l-BUS)  interface.  The 
PF -boot  strap  program  is  implemented  with  a smau  Read-Only-Memory  ( ROM  » contained  in  the 
I OH'  This  memory  resides  tn  the  remaining  memory  address  space  between  the  program/data 
memory  limit  (8k)  and  the  maximum  processor -addressable  memory  location  (64k).  it  is  the 
final  responsibility  of  the  PF -boots!  rap  program  to  enter  the  normal  processing  entry  address 
("(JO"  Address)  after  initialization  has  been  accomplished. 

As  mentioned  above,  the  initialization  signal.  CLFAK/RESFT.  must  be  externally  supplied. 
The  occurrence  ot  this  signal  oveirides  and  causes  the  cessation  of  all  other  PF  activity,  as  shown 
■n  the  timing  diagram  of  Figure  7b.  Any  l-BUS  data  word  transfer  activity  presently  in  progress 
.t  the  time  of  CI.FAR  RFSFT  occurrence  is  allowed  to  finish  (within  a specified  time-out 
period)  before  actual  initialization  activity  begins  to  prevent  possible  destruction  of  memory 
data. 


The  Initialization  Bootstrap  program  is  a normal  sequence  of  PF  instructions  contained  in 
a sinaii  hardware  Read  Only  Memory.  The  execution  of  this  piogram  controls  all  inner-PE 
parameter  initialization  as  well  as  governing  the  interface  between  the  System  Program  Loader 
device  and  the  PF  to  which  it  is  attached  (via  the  PE’s  I/O  data  transfer  channel).  The  actual 
initialization  procedure  followed  during  system  start-up  is  discussed  in  Section  Viil.  The 
necessary  instruction  sequence  required  to  implement  this  tentative  initialization  procedure  was 
coded,  consequently . it  was  decided  that  an  ROM  program  size  of  32  words  would  be 
satisfactory  to  achieve  all  initialization  control  procedures. 

4.  PE  Gock  Control 

This  functional  element  of  the  lOlU  is  r -sponsible  for  generating  the  prope;  clock 
frequencies  used  internally  to  the  PF  and  providi  tg  the  necessary  gating  controls  required  to 
inhibit  PF  operation  in  conjunction  with  maintenance  operations. 

All  internal  PF  clocks  will  be  generated  from  an  externally  supplied  "free"  clock  source.  A 
frequency  of  8 MHz  is  presently  envisioned  as  the  desired  free  clock  frequency.  This  clock  is 
then  divided  down  to  the  appropriate  PF  clock  frettuency  which  is  technology-dependent,  but 
presently  assumed  to  be  in  the  I-  to  2-.MHz  range,  (lock  drivers  are  then  applied  to  this  clock 
signal  within  the  lOlU  (after  gating)  to  allow  distribution  to  all  PF  elements. 

5.  ftocessor  Memory  Interface  Control 

This  functional  element  of  the  IOIU  performs  the  necessary  control  operations  associated 
with  providing  interface  protocol  compatibility  between  the  IOIU  and  the  internal  PF  data 
exchange  bus  ( l-BUS » which  interconnects  each  functional  unit  of  the  PF.  All  data' command 
exchange  between  the  processor  memory  (P  M)  and  the  IOIU  are  accomplished  via  this  internal 
bus.  The  P M interface  contiol  section  contains  the  logic  associated  with  decoding  program 
instructions  requiring  IOIU  action.  A list  ot  I'O  commands  (instructions)  is  given  in  Table  1 6. 
The  P M interface  control  section  also  contains  the  hardware  elements  required  to  retain  and 
present  tli  < ’U  interrupt  stimuli  to  the  processor  interrupt  input  via  the  l-BUS.  This  logic 
performs  , g.  ^in-controlled  masking  of  .-ach  separate  interrupt  stimulus  and  provides  protocol 
compliance  with  the  processor  interrupt  related  operations.  I/O  interrupts  are  listed  in  Table  17. 
A functional  block  diagram  ot  the  P M Interface  section  is  shown  in  Figure  73. 
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Flfure  76.  PE  Initialization  <Oear/Re*et)  Control  Signal  Sequence 


TAILS  I*.  KNU  COMMANDS 
(INSTRUCTIONS) 

Procemar  Output  (Write) 

1 Activate  Autonomous  I nutter 

2 Deactivate  Autonomous  Transit! 

3.  Load  AutononxHis  Data  Channel  Status 

4.  load  Programmable  Time  Interval 

ftocemm  luput  (leal): 

I.  Send  Autonomous  Data  Channel  Status 

2 Send  Current  Duller  Address 

3 Send  Current  Butter  Length 

4.  Ser.d  Current  Link  Address 

5.  Send  Interval  Timer  Value 

Note  Status  Wind  Inhumation  includes 

• Autonomous  Data  Channel  Bus>  Available 

• Chaining  Enabled  Disabled 

• Current  Transfer  Ihreition  (In, Out  I 

• Interrupt  Stimulus  Flap 


TABU:  17.  KXll 
INTERRUPTS 

1 Programmable  Interval  Timer 

2 Externa)  Interrupt 

3.  Buffer  Transfer  Complete 

Note  Interrupts  are  listed  in  order 
of  decreasing  priority 


D.  HARDWARE  COMPLEXITY 
ESTIMATES 

To  allow  a relatively  accurate  assessment 
of  the  impact  of  the  above  lOHJ  functional 
design  on  LSI  implementation,  a device 
complexity  estimate  was  performed  for  each 
functional  element  of  the  IOIU.  Complexity 
estimates  were  made  in  unit  of  TTL* 
equivalent  gates,  using  the  same  rationale  and 
procedure  as  desrribed  previously  in  the 
analagous  sizing  effort  performed  for  the  Bus 
Interface  Unit  (BIU)  in  Section  III.  The  gate 
sizing  results  are  given  in  Table  18. 


table  ib.  wurr/ounvr  interface  unit 

FUNCTIONAL  HARDWARE  COMPLEXITY  ESTIMATES 


Functional  Element 

Autonomous  Data  Transfer  Channel 
Programmable  interval  Timer 
PE  Initialization  Control 
PE  Clock  Control 
Processor  Memory  Interface 


Hardware  Complexity 
(TTLteqtMvaletit  gates) 

726 

230 

37  + 512  bits  ROM 
50 
1 2*) 


Total  IOIU  =1.172  + 512  bits  ROM 


SECTION  VI 

PE  IMPLEMENTATION  CONSIDERATIONS 


A.  INTRODUCTION 

Pus  section  considers  the  technology,  performance,  packaging,  and  costs  associated  with 
DP  M PI  hardware.  The  first  part  looks  at  the  current  technologies  and  their  trends  This 
includes  considerations  ot  the  ease*  ot  fabrication,  packing  density,  performance,  and  operating 
temperature  range.  The  next  subsection  looks  at  the  effect  of  the  technology,  processor 
architecture,  and  the  instruction  execution  to  determine  the  performance  that  can  be  expected 
of  the  DP'M  PE.  Partitioning  and  packaging  are  examined  to  determine  the  most  flexible  and 
least  expensive  method  of  building  the  PE.  Special  consideration  is  given  to  ensure  that  future 
growth  and  advancements  in  technology  can  be  incorporated  as  they  become  available.  One 
feature  of  the  partitioning  that  greatly  enhances  this  ability  is  the  separation  of  the  processor 
from  the  memory  (Figure  77)  and  the  use  of  an  asynchronous  demand /response  transfer 
intercommunication  structure  between  the  two  modules.  This  allows  the  memory  and.  or  the 
processor  technology  to  be  easily  changed  without  adversely  affecting  the  timing  of  either. 
Finally  the  cost  of  the  PE  is  considered.  It  is  shown  that  a DP'M-like  microcomputer  can  offer 
significant  cost  performance  features  for  avionics.  The  cost  reduction  for  a DP;M  PF  is  not  as 
great  as  that  expected  for  commercial  microcomputers  because  of  military  environmental  and 
reliability  requirements. 
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Figure  77,  DP/M  Block  Diagram 
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B.  TECHNOLOGY 


It  appears  hkel>  that  adequate  DP  M PH  performance  can  be  met  with  current  semicon- 
ductor technologies,  which  imply  low  risk  and  perhaps  low  cost.  As  with  most  systems  using 
semiconductor  devices  that  are  currently  available,  the  cost  and  performance  of  the  system  are 
closely  tied  to  the  technology  and  packaging  of  the  system.  Both  current  technologies  and  likely 
future  technologies  have  been  examined  for  their  applicability  to  DP'M  cost  and  performance 
goals. 


The  current  semiconductor  technologies  include: 

Bipolar 

Standard  (TTl . DTL.  1 C L.  etc.  I 
High  density  tl:l,  HIT  . <*’L.  etc.) 

MOS  (metal  oxide  semiconductor) 

PMOS  (positive-channel  MOS  devices) 

NMOS  (negative-channel  MOS  devices) 

CMOS  (complementary  MOS  devices) 

Special  process'  lg  (silicon  gate,  ion  implanted,  depletion  load,  and  self-aligned 
gate) 

Tutu-  semiconductor  technologies  include: 

MOS 

SOS  (silicon  on  sapphire) 

MNOS  (metal  nitride  oxide  semiconductor  devices) 

CCD  (charge-coupled  devices) 

Magnetic 

Bubble. 

The  DP  M technology  and  packaging  research  has  considered  previous,  present,  and 
projected  trends  in  the  semiconductor  industry,  particularly  with  respect  to  the  newer  tech- 
nologies. In  the  past,  certain  technologies  with  definite  performance  advantages  have  never  been 
able  to  make  the  transfer  from  the  research  laboratory  to  the  commercial  marketplace.  For 
example,  silicon  on  sapphire  (SOS)  has  been  in  the  research  laboratory  for  nearly  10  years,  but 
has  not  been  used  extensively,  except  in  military  applications,  because  of  its  relatively  high 
production  cost  when  compared  to  that  of  other  commercial  technologies.  In  contrast,  the 
integrated  injection  logic  (l2L)  has  gone  from  laboratory  research  in  1971  to  a commercial 
product  (as  a memory  cell  in  Intel’s  256-bit  RAM)  introduced  in  June  of  1973.  In  1974  several 
new  consumer  (watches)  and  commercial  (4-bit  register  file/ALU  chip)  lJL  products  were 
developed.  Thus,  in  less  than  3 years,  this  technology  has  gone  from  the  laboratory  to  volume 
production.  The  DP/M  technology  research  started  with  currently  available  technologies  as 
candidates  for  baseline  implementation  for  the  PH,  and  the  effort  was  directed  toward  the 
development  of  a cost-effective  processing  element  for  the  1978  to  1980  time  period. 
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I.  Memory  Technology 

In  specifying  a memory  technology  for  DP  M.  several  factors  were  considered.  All  the 
current  memory  technologies,  with  the  exception  ol  magnetic  wires,  cores,  and  surface  recording 
techniques,  make  use  of  photographic  techniques  to  define  the  memory  cell  The  photographic- 
process  used  has  reached  the  level  of  development  where  it  is  limited  by  the  wavelength  of  light. 
This  limits  line  widths  and  or  spacing  to  about  0.0001  inch.  Thus,  the  xi/e  and  cost  of  a memory 
cell  is  directly  related  to  a cell's  complexity  tTable  l‘M.  file  static  semiconductor  cells  are  the 
most  complicated,  typically  having  six  devices  i iransistors.  diodes,  and  or  resistors!  per  bit  cell. 
The  rewer  dynamic  NMOS  memories  have  two  devices  (one  transistor  and  one  capacitor)  per  bit 
cell,  file  newer  secondary  memories  generally  have  a single  device  per  bit  cell.  Other  facto'  that 
affect  bit  cell  si/e  include  the  device  and  or  process  complexity  . The  current  magnetic  bubble 
technology  requires  two  patterned  metal  layers  to  form  its  cell.  The  dynamic  NMOS  requires  one 
diffusion,  two  levels  of  conductors,  and  four  to  five  mask  steps,  while  the  bipolar.  CMOS. 
MNOS.  and  C'Cf)  requ-re  several  more  steps  over  the  NMOS.  Another  factor  that  affects  bar  size, 
and  thus  cost,  has  to  do  with  peripheral  ton  chip)  circuitry.  The  bar  utilization  for  memory  cells 
ranges  from  a low  of  22  percent  for  ('CDs  to  a high  of  62  percent  for  magnetic  bubl>!  ‘s.  These 
cell  and  bar  utilization  factors  are  what  cause  the  20-to-l  variation  in  bit  density.  When  all  these 
factors  are  taken  into  account,  however,  it  is  f'  e same  photographic  processing  that  limits  the  bit 
density  for  all  these  technologies. 

In  selecting  a memory  technology  for  the  DP/M  PH,  the  requirement  for  a military 
temperature  range  has  a strong  influence.  The  high  temperature  makes  it  difficult  to  use  any 
technology  that  makes  use  of  stored  charge  such  as  dynamic  NMOS  and  CCDs.  The  reason  for 
this  is  the  increased  recombination  and  surfac*  leakage  currents  associated  with  the  +125°C 
operation. 

Semiconductor  manufacturers  are  gaining  experience  in  building  the  current  4K  dynamic 
NMOS  memory  chips.  The  maximum  refresh  time  for  these  0°  to  70°C  parts  is  typically 
guaranteed  at  2 ms.  The  current  square  arrays  of  memory  cells  (64  X 64)  of  a 4K  chip  require  a 
refresh  cycle  every  31  #is.  With  the  current  cycle  tune  of  400  ns.  the  refresh  takes  about  1.3 
percent  of  the  available  cycles.  It  has  been  found  possible  to  screen  parts  for  +90°  C operation 
which  still  have  2-ms  refresh  times.  There  are  indications  that  these  parts  may  be  able  to  operate 
at  +1254C  if  the  refresh  time  is  reduced  by  8 to  I (0.25  ms).  If  designed  with  a I6K  (128  X 
128)  chip  operated  at  +125T,  it  would  appear  conceivable  that,  by  refreshing  128  times  every 
0.25  ms.  the  memory  might  be  made  to  work.  This  would  amount  to  about  1 1 percent  of  the 
available  cycles  devoted  to  refresh.  These  data  indicate  that  it  is  too  early  .o  rule  out  a dynamic 
NMOS  memory  as  a military  temperature  DP'M  technology  candidate.  Conversely,  other  factors 
must  be  considered.  There  is  currently  no  evidence  that  anyone  has  actually  tried  to  use  dynamic 
NMOS  devices  at  temperature  extremes  in  a system  to  determine  the  problems  that  may  exist. 
Several  people  knowledgeable  in  the  technology  have  serious  reservations  as  to  potential 
reliability  problems  that  may  exist  at  continued  operation  at  elevated  temperatures.  Alternately, 
dynamic  NMOS  appears  to  be  the  only  practical  way  to  getting  the  bit  density  that  the  DP/M  PK 
needs.  All  other  approaches  are  much  more  expensive  in  terms  of  size,  weight,  and  cost.  Even  if 
the  dynamic  NMOS  dev:ce  can  be  made  to  work  over  the  temperature  range,  it  will  not  be 
without  its  disadvantages. 
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TABLE  I*.  DP/M  MEMORY  TECHNOLOGY 


Because  of  its  high  refresh  rate  at  elevated  temperatures.  NMOS  standby  power  will  be  at 
least  10  times  that  ot  ( MOS.  Thus,  any  standby  power  source  for  a dynamic  NMOS  memory 
must  be  capable  of  at  least  10  times  the  power  that  a CMOS  memory  would  require  to  be 
nonvolatile.  Of  course,  the  advantage  ol  the  dynamic  NMOS  is  4 times  the  bit  density.  For  the 
OP'M  baseline  the  primary  choice  is  dynamic  NMOS  tor  packing  density  followed  by  '"'MOS  for 
its  better  temperature  and  power  characteristics  A possible  contender  is  Integrated  Injection 
Lope  < 1 2 L ).  The  !2L  technology  seems  to  have  good  potential  but  has  not  seen  extensive 
memory  application  to  date  Many  ot  the  read  mostly  memories  ( RMM  > such  as  MNOS  are  either 
quite  slow  by  comparison  and  or  much  more  difficult  to  produce.  Because  of  these  reasons  there 
appears  to  be  little  commercial  interest  in  such  technologies,  and  high-volume  commerc.al 
production  is  one  means  m achieve  the  desired  DP'M  cost  goals. 

rhe  recommended  baseline  DP'M  memory  chip  has  the  following  features 
*16K  bits/chip  <1978  to  19X0) 

8K  words  X 2 hits 

Single  device  cell  dynamic  NMOS 

0.33  to  0.5  /is  access  time. 

Over  the  next  5 years,  substantial  improvements  can  bt  expected  with  representative 
characteristics  shewn  in  Table  20. 

a.  Dynamic  SMOS 

With  improved  layout  and  sense  amplifier  design,  a 2-to-l  improvement  in  cell  size  coupled 
with  a larger  bar  should  allow  dynamic  NMOS  to  reach  16K  bits  per  chip. 

b.  Static  SMOS 

A 2-to-l  improvement  in  layout  and  bit  cell,  coupled  with  a 2-to-l  bar  size  increase, 
should  allow  static  NV.3S  to  reach  4K  bits  per  chip. 

c.  CMOS 

With  improved  layout  and  isolation  techniques  (such  as  SOS),  a 4-to-l  improvement  in  cell 
si/e  coupled  w;th  a larger  bar  should  allow  CMOS  to  reach  4K  bits  per  chip. 

d.  Bipolar 

With  improved  isolation  techniques  (such  as  oxide  isolation)  and  improved  memory  cells 
(using  integrated  injection  logic),  a 4-to-l  improvement  in  cell  size  should  allow  bipolar  memories 
tc  reach  4K  bits  per  chip. 

e MNOS 

With  improved  layout  and  device  technology,  a 4-to-l  improvement  in  cell  size  and  an 
increased  bar  size  should  allow  MNOS  memories  to  reach  16K  bits  per  chip. 
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TABLE  20.  CURRENT  MEMORY  DEVELOPMENT 
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/ CCD 


With  improved  layout  and  multiple  hits  per  sell,  a 10-to-l  improvement  in  ell  si/e.  a 
2-to-l  improvement  in  bar  utili/ation.  and  a larger  bar  should  allow  ( ( |>  memories  to  ua  li  52F 
bits  per  ehip. 

g.  Magnetic  Bubble 

By  developing  the  single  patterned  metal  layer  te<.hno|og\  coupled  wtili  Vr.iy  photo- 
graphic processing  (reduced  wavelength  to  allow  smaller  line  width  I.  an  vto-l  improvement  in 
cel!  si/e  voupled  witn  a larger  ship  should  allow  magnetu  bubbles  to  ic.kIi  _ ^ (>K  bits  pet  ship 

2.  Logic  Technology 

For  the  processor.  BIC.  and  I O logic  chips,  several  LSI  technologies  have  the  required 
pertormance  ot  under  4*is  average  instruction  time  (I  igure  "8)  These  include  NMOS. 
SOS-(  MOS.  and  Is  I 

As  with  the  memory . one  of  the  most  important  considerations  in  selecting  an  1 SI 
technolog>  lor  the  processor  is  the  operating  temperature  range  and  the  manufacturing  associated 
with  the  technology  cost.  The  bipolar  technology  le.g  . TTL.  I31  1 has  a maior  advantage  over 
the  MOS  technologies  in  that  it  does  not  require  special  layouts  and  or  processing  to  op>-  ate 
over  a full  military  temperature  range.  To  operate  over  this  range.  MOS  devices  generally  require 
either  a much  larger  layout  (2  to  I)  with  guard  rings  around  each  device  (as  with  CMOS. 
Figure  ',t>)  cr  special  processing  as  with  SOS.  These  special  techniques  cause  the  military  version 
to  be  significantly  more  expensive  than  a commercial  version.  Thus,  from  a cost  standpoint,  it 
would  be  better  to  use  j bipolar  technology  such  as  I3  L lor  the  processor  and  take  advantage  of 
any  commercial  production  base.  An  additional  advantage  ot  bipolar  is  the  ease  ot  interfacing, 
which  could  significantly  affect  the  overall  system  cost  and  flexibility . 

The  best  bipolar  LSI  candidate  is  Integrated  Injection  Logic  (I3L)  which  applies  linear 
circuit  techniques  to  form  a high-density,  low-power  logic  circuit.  From  a circuit  standpoint,  a 
lateral  PNP  transistor  is  used  as  a current  source  load  for  the  inverted  NPN  logic  transistor 
<Figue80).  The  logic  transistor  can  have  multiple  collector  outputs,  and  the  desired  logic- 
operation  is  performed  by  wire-ANDing  several  of  these  collectors  together.  The  l:  L approach 
uses  new  and  novel  device  and  circuit  techniques  rather  than  a new  technology  to  achieve  its 
high  performance  and  packing  density.  Ot  course,  as  with  any  device  senes,  some  process 
optimization  will  be  required  to  achieve  high  yields  and  improve  performance. 

In  addition  to  operating  temperature  range,  the  other  important  items  to  consider  in  the 
selection  of  an  LSI  technology  are  power  dissipation  (speed  power!,  performance  (propagation 
time),  and  chip  size  (gates  per  unit  area).  Of  the  available  technologies  (Table  21).  IJL  has  the 
best  speed,  power,  and  gate  density  attributes.  It  is  taster  than  MOS  devices,  but  somewhat 
slower  than  other  bipolar  devices.  Further,  as  pointed  out  above,  since  it  is  a bipolar  device.;  a 
military  temperature  range  version  can  be  simply  selected  from  the  commercial  devices,  thus 
taking  advantage  of  volume  commercial  production.  I3  L is  the  recommended  technology  for  the 
logic  portion  of  DP'M.  There  should  he  no  problem  interfacing  l3L  logic  with  NMOS.  CMOS,  or 
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Figure  7**  ( omplementarv  MOS  I CMOS  > 


r\BLE  21  UP  M PROC  fcSSt'R  TECHNOLOGY 


Speed  Power 
fpJl 

Propagation  Time 
ins» 

Gates*  per 
10.000  mils' 

Standard  bipolar 
(TTL.  DTL.  ECU 

10  to  100 

: to  2o 

'0  to  200 

High  densit>  bipolar 
(l3L| 

1 to  < 

20  to  100 

400  to  ’00 

MOS 

10  lo  100 

^0  to  100 

200  lo  *100 

(PMOS,  NMOS.  CMOS! 

•tquiwlenl  gates  imlnde  h:jdv  hundint  pau>.  j rf  ha:  edges 
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INVERTED  NPN 


LATERAL  PNP 


4 

Figure  SO.  Integrated  Injection  Logic  I*  L 


bipolar  memories  since  the->e  technologies  are  all  normally  built  with  TTL  level  interface 
compatibility.  The  recommended  DP'M  baseline  logic  chips  have  the  following  characteristics: 

I3 1.  technology 

3K  to  4K  gates  chip  l l‘)7X  to  l‘)X0) 

XO  jiW  jnd  20  ns  internal  gate 
2 mW  input  (TTL  compatible) 

6 mW  output  (TTL  compatible) 

It  should  be  noted  that  some  ot  the  more  complex  l:L  devices  currcntlv  in  production 
(e.g..4-bit  processing  element  chips)  have  up  to  1.450  Bates  per  chip.  Thus,  with  the  partitionings 
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shown  in  Section  IV  (especially  the  2-chip  processor)  it  is  possible  to  start  development  of  the 
DP^M  processor  chip(s)  in  1975.  The  most  likely  alternative  to  l2L  is  NMOS  which  has  good 
density  and  performance.  Its  major  disadvantage  is  that  it  does  not  normally  perform  well  over 
the  the  full  military  temperature  range.  Neither  CMOS  nor  SOS  technologies  appear  very 
attractive  because  of  their  relatively  expensive  manufacturing  process  and  lack  of  commercial 
production  base  experience.  Both  technologies  have  advantages  for  military  applications  but 
neither  have  done  well  in  the  commercial  high-volume  low-cost  market. 

3.  Summary  of  Technology  Recommendations 

Based  on  the  current  state  of  technology  development,  it  appears  that  dynamic  NMOS  is 
the  best  choice  for  the  memory  if  it  can  be  made  to  work  over  the  military  temperature 
environment.  The  best  alternative  is  probably  CMOS  with  its  lower  power  and  better  temperature 
characteristics,  but  at  the  expense  of  density.  For  the  logic  portion  of  DP/M  the  newer  I2L 
technology  appears  to  be  the  best  choice.  One  potential  advantage  of  l2L  is  that  it  may  be  easier 
to  mute  it  radiation  hardened  without  adversely  affecting  its  cost,  based  upon  the  following 
general  information: 

I2  L is  a bipolar  semiconductor  technology  and  is  thererjre  comparatively  “harder” 
than  MOS  technology 

l2L  has  few,  if  any.  nonactive  device  functions  to  be  exposed  to  radiation 

Photocurrent  (i.e.,  radiation-induced  current)  is  one  of  the  methods  used  to  power 
an  I2  L device. 

The  best  alternative  is  probably  NMOS  except  for  its  potential  temperature  problem.  The  next 
choice  would  be  CMOS,  but  it  suffers  from  poor  packing  density. 

C.  PE  PERFORMANCE  PROJECTIONS 

The  performance  of  the  DP/M  processor  is  dependent  on  the  number  of  microsteps 
required  for  each  operation  and  the  time  for  each  microstep,  plus  the  memory  speed.  Examples 
of  the  number  of  microsteps  required  for  instruction  execution  are  given  in  Section  IV.  The 
number  ranges  from  as  few  as  two  for  the  simpler  instructions,  such  as  Add  Constant  Short  and 
Add  Register,  to  over  20  for  multiply  and  divide.  The  time  for  each  microstep  depends  on  the 
number  of  levels  of  logic  (gates)  between  registers  and  the  propagation  time  per  level.  Normally, 
the  number  of  levels  of  logic  between  registers  is  dominated  by  the  control  and  carry 
propagation  paths  through  the  arithmetic  logic  unit  (ALU).  This  path,  counting  the  multiplexers, 
ALU  data/control/carry,  and  register  input/output,  typically  has  10  to  20  levels  of  logic. 
Depending  on  the  logic  technology  used,  the  propagation  time  per  level  can  be  in  the  20-  to 
50-ns  range.  This  gives  a range  of  0.2  to  1.0  ps  per  processor  microcycle.  By  minimizing  the 
number  of  logic  levels  and  projecting  technology  performance,  i>  would  appear  that  microcycles 
in  the  0.25-  to  0.5-ps  range  in  the  1978  to  1980  time  period  are  reasonable  for  the  DP/M  PE. 

When  considering  the  memory  performance  needed  to  match  the  processor,  the  number  of 
levels  of  logic  in  the  "address  out”  and  the  "data  in”  lines  should  be  minimized.  Then  to  match 
the  memory  to  the  processor,  the  memory  should  have  an  access  time  20  to  30  percent  less  than 
the  processor’s  microcycle,  and  the  memory  cycle  should  be  no  longer  than  the  processor 
microcycle.  The  memory  technologies  that  have  been  proposed  should  have  access  and  cycle 
times  with  this  range  in  the  1978  to  1980  time  period,  fhus.  the  DP/M  PE  should  be  able  to  run 
with  a 2-  to  4-MHz  clock.  Figures  81  and  82  show  the  microcycles  involved  in  the  extended 
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STANDARD  FORMAT  INSTRUCTIONS 
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Figure  82.  Standard  Fermat  Instructions 


short  and  standard  short  format  instructions.  With  the  exception  of  a few  instructions  such  as 
multiply,  divide,  and  shift,  the  instructions  take  from  2 to  5 microcycles.  Excluding  these 
instructions  and  assuming  an  average  of  4 microcycles  per  instruction  would  give  a processing 
rate  of  500  to  1000 kilo  instructions  per  second  (KIPS)  Including  10 percent  multiply/divide 
operations  would  drop  the  rate  to  330  to  660  KIPS.  This  level  of  DP/M  PE  performance  will  be 
more  than  adequate  to  do  a large  portion  of  the  avionics  problem. 

D.  PE  PARTITIONING  AND  PACKAGING 

C omparing  the  complexity  ol  the  various  PI-  elements  based  on  the  DP/M  design  analysis 
(Table  22)  to  projected  semiconductor  technology  trends,  it  appears  that  in  1978  to  1980  the  PE 
cannot  be  economically  fabricated  as  a single  semiconductor  chip.  Further,  the  memory 
complexity  dominates  the  PE.  An  important  consideration  in  the  partitioning  of  the  PE  is  to 
make  it  modular  to  be  able  to  tak-  advantage  of  technology  'idvancements  and  commercially 
available  parts  and  tailor  the  processing  element  memory  and  I/O  to  the  particu'ar  application. 

There  are  several  factors  to  be  considered  in  specifying  the  partitioning  and  packaging  for 
DP  M PF.,  These  include  si^e.  weight,  cost,  and  reliability.  The  current  semiconductor  industry 
standard  is  the  dual  in-line  package  (DIP).  This  package  is  rectangular  in  shape  and  has  two  rows 
of  pins  on  100-mil  centers  pointing  down  along  the  long  sides.  Low-cost  plastic  and  high- 
reliability  ceramic  packages  are  commercially  available  in  this  form  factor.  There  are  currently 
packages  with  6.  8.  14.  16,  18.  20.  22,  24.  28.  40,  48.  and  6^  pins  with  this  form  factor.  The 
ceramic  version  of  this  package  is  the  one  recommended  for  LSI  devices  for  the  DP/M  PE. 


TABLE  22  PROCESSING  ELEMENT  COMPLEXITY 


Complexity 

(gates/bit) 

Packages 

Power 

Functional  Unit 

(xiooo) 

Type 

Total 

Pins/Package 

(watts) 

Processor 

3 to  4 

1 to  2 

1 lo  2 

48 

07 

Memory  controller 

0.6  to  0 8 

1 

! 

48 

0.2 

Memory 

c 128  to  132 

1 

8 to  9 

20 

32 

Bus  interlace3 

4 to  6 

3 

8 

14.  20.  48 

1.7 

1 O interlace^ 

1 lo  1 5 

2 to  6 

6 to  9 

16.  18.  24.  28.  40.  48 

1.9  to  2 

J I stimatcs  do  nut  time  but  line  drive!  receive!  devices 

^Variation  in  evtinulcv  is  caused  by  diiferent  partitioning  apr  'aches.  Device  quantity  estimates  do  nol 
include  a tew  miscellaneous  standard  devices  required  for  Pi  initialization  control  and  Ph  clock  control 
'•Without  and  with  I -hit  paritv 

Mote  Power  dissipations  shown  are  conservative,  worst  case  estimates  reflectinf  implementation  with  both 
I’L-ISI  (low-power)  Jones  and  standard  technologs  (low-power  Schottky  bipolar'  devices 
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The  next  consideration  is  whether  the  whole  PE  should  be  placed  into  a single  hybrid 
package  using  beam  lead  (or  wire-bonded)  chips  or  into  multiple  packages  mounted  on  a printed 
circuit  board.  The  single  hybrid  package  has  the  smallest  size  and  weight  and  also  has  the  highest 
reliability  if  beam  lead  chips  are  used.  Its  major  disadvantage  is  a very  high  cost.  The  hybrid 
package  can  be  as  much  as  10  times  as  expensive  as  separate  packages  mounted  on  a printed 
circuit  board.  When  the  size  of  all  the  peripheral  devices  such  as  clocks,  power  supplies,  and 
interface  circuitry  are  considered,  it  is  unlikely  that  the  modest  size  reduction  gained  by  using 
the  hybrid  package  can  justify  its  high  cost.  Thus,  for  the  DP/M  PE,  it  is  recommended  that  each 
integrated  circuit  chip  be  mounted  in  a separate  package.  The  PE  is  then  fabricated  by  placing 
these  packages  onto  a printed  circuit  board  using  conventional  techniques.  This  should  result  in  a 
PE  with  an  approximate  4-  by  5-inch  (excluding  peripheral  circuitry)  form  factor.  Because  of  the 
low  power  and  small  size  of  the  DP/M  PE.  it  is  envisioned  that  the  PE  will  normally  be  a part  of 
some  larger  c;  stem  As  such,  it  is  expected  that  the  PE  would  be  a single  card  within  a line 
replaceable  unit  (LRU).  In  this  case  it  would  share  power,  cooling,  and  packaging  with  the 
remainder  of  the  equipment  within  the  LRU. 

The  number  of  pins  per  package  also  affects  the  package  size  and  greatly  affects  the  device 
cost.  The  partitioning  of  the  PE  must  be  done  carefully  to  minimize  the  number  of  pins  per 
package.  Conversely,  as  the  number  of  pins  is  reduced  beyond  some  point,  performance  and  chip 
count  will  suffer  because  different  information  must  be  multiplexed  onto  the  same  lines. 
Examples  of  this  are  the  processor’s  data  and  address  sharing  the  same  lines.  The  address  is 
placed  on  the  lines  first  and  latched  into  an  external  register  (possibly  on  the  memory  chips). 
Then  the  data  is  transmitted  over  the  same  set  of  lines.  The  disadvantage  is  the  increase  in 
execution  time,  external  circuitry,  and  complexity.  The  advantage  is  a 2-  to  1 reduction  in 
address/data  pin  count.  As  discussed  in  Section  IV,  it  is  recommended  that  the  data  and  address 
be  placed  on  different  pins  to  maintain  maximum  performance. 

1.  Processor 

One  example  of  a commercially  available  8-bit  microprocessor  is  the  Intel  8080  which  uses 
a 40-pin  DIP.  The  40  pins  are  divided  into  8 data,  16  address,  and  various  control,  clock,  and 
power  pins.  The  next  larger  commercially  available  package  is  a 48-pin  DIP  that  will  be  adequate 
for  the  DP/M  processor.  This  would  allow  for  16-bit  data,  16-bit  address,  and  the  various 
control,  clock,  and  power  pins.  Figure  83  shows  a one-  and  a two-chip  partitioning  of  the 
processor  using  this  48  pin  package.  Details  of  the  processor  design  and  complexity  are  given  in 
Section  IV. 

2.  Memory  and  Control 

As  discussed  in  Section  IV,  the  memory  control  is  a separate  DP/M  element  (Figure  84). 
This  controller  handles  memory  refresh,  parity,  and  write  protect  of  the  memory  chip  shown  in 
Figure  85.  In  addition,  the  memory  control  chip  handles  the  1-BUS  timeout  watchdog  timer 
mentioned  in  Section  IV.  The  refresh  (if  required)  is  controlled  by  a memory  control  chip  which 
allows  easy  modification  to  handle  different  classes  of  memories.  A bus  address  decoder  is  also 
included  to  differentiate  between  I/O  and  memory  operations.  If  other  than  the  first  8K  of 
memory  is  to  be  addressed  by  a controller,  an  inverter  must  be  placed  in  one  or  more  of  the 
memory  control  address  lines.  The  memory  controller  has  a chip-enable  line  which  drives  the 
nine  1 6K-bit  memory  chips. 
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Figure  84.  DP/M  Memory  Controller 


The  F-BUS  master  clear/reset  line  is  used  to  command  the  memory  controller  to  place  the 
memory  into  the  powered-down,  or  standby,  state.  This  is  used  in  conjunction  with  an  auxiliary 
power  source  to  allow  the  data  in  the  memory  to  be  retained  during  the  loss  of  primary  power 
with  minimum  power  consumption,  thus  relaxing  auxiliary  power  supply  complexity. 

The  memory  control  chip  generates  and  checks  memory  parity  and  enforces  write 
protection.  As  discussed  in  Section  IV,  the  write  protection  consists  of  a pair  of  registers  which 
establish  the  read/write  and  the  read-only  regions.  If  a parity  error  or  write-protect  error  occurs, 
the  memory  control  chip  generates  an  interrupt.  When  the  processor  acknowledges  the  interrupt, 
the  memory  controller  issues  the  interrupt  trap  address  over  the  data  lines.  The  memory  control 
interrupt  mask  and  write-protect  bounds  registers  are  accessed  by  unique  I/O  device  Command 
Address  Words  (CAWs).  The  memory  controller  is  in  a 48-pin  package  and  has  approximately 
763  gates. 
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(3.2  WATTS  TOTAL) 


•ASSUMING 
DYNAMIC  NMOS 

DATA  I/O  ■» / J | 


Figure  85.  DP/M  Memory 


3.  Bus  Interface  Unit 

The  advantages  afforded  by  I2  L bipolar  LSI  technology  for  the  DP/M  processor  apply  to 
the  bus  interface  unit  (B1U)  as  well.  The  performance  characteristics  of  I2  L appear  more  than 
adequate  for  the  logic  operation  speeds  required  for  all  BIU  operations,  including  the  Manchester 
II  encode 'decode  functions  for  a 1-Mbps  data  rate.  With  the  decision  thus  made  to  employ  I2L 
technology  in  the  implementation  of  the  BIU,  the  final  tradeoff  consideration  is  one  of  physical 
partitioning  and  packaging.  The  two  candidate  choices  are  “single-chip”  and  “multichip” 
packaging. 

Major  tradeoffs  can  be  encountered  in  the  area  of  device  complexity  and  packaging.  The 
approach  chosen  to  partition  a functional  design  into  unique  physical  monolithic  devices  is 
primarily  dependent  upon  the  following  criteria: 

Device  complexity  requirement 

Gate  density 

Nonrec’irring  cost  (layout,  checkout,  debug) 

Recurring  cost  (yield,  producibility,  unit  test,  packaging  assembly) 

Technology  requirements 
Performance 
Environment 


Packaging 

Commercial  compatibility 
Recurring  cost 
Device  reliability 

Technology  requirements  can  usually  be  determined  at  the  outset  from  the  device's 
functional  requirements.  Major  tradeoffs  are  encountered  in  the  area  of  device  complexity  and 
packaging. 

Ultimately,  the  problem  tradeoff  becomes  what  shall  be  referred  to  as  ‘ ultra  iarge-scale 
integration,”  or  extremely  complex  custom  LSI  single  chip  implementation,  versus  partitioning 
into  a set  of  less  complex  multiple  LSI  devices.  Evaluation  criteria  for  the  DP/M  application 
should  be  weighed  in  units  of  added-value-per-cost  requirements  for  each  approach. 

Typically,  single-chip  implementation  means  large  devices  for  complex  implementations 
such  as  the  envisioned  B1U  <4,6Q0-gate  complexity  estimated)  with  high  package  pin-out  (I/O 
pins)  requirements.  In  summary,  a single-chip  BIU  would  require  a large,  complex  custom  LSI 
device  contained  within  a custom  package  with  device  realization  optimistically  speculated  in  the 
late  1 470s  to  early  1980s. 

The  multi-chip  LSI  approach  possesses  merits  in  all  areas  where  complex,  single-chip  LSI 
suffers  economic  drawbacks.  Disadvantages  ol  the  multi-chip  approach  are  PE  size  increase, 
reduced  reliability,  and  some  logistics  complexity  increase.  These  disadvantages,  however,  are 
judged  to  present  only  minor,  second-order  effects  as  rationalired  oelow. 

Overall  PE  size  may  actually  be  decreased  by  multiple-chip  implementation  depending  on 
the  larger  custom  package  size  in  comparison.  For  example,  in  present  catalog  dual  in-line 
integrated  circuits,  a relatively  complex  24-pin  package  requires  more  board  area  than  two  16-pin 
packages  with  perhaps  half  the  device  complexity  each;  the  end  result  is  usually  driven  by 
package  pin-out  requirements.  However,  these  size  considerations  for  .he  BIU  appear  to  be 
insignificant  because  of  the  small  magnitude  of  the  differences  involved. 

Semiconductor  LSI  device  reliability  is  roughly  proportional  to  the  complexity  of  the 
device  implementation.  Therefore,  there  does  not  appear  to  be  a significant  reliability  difference 
between  the  implementation  choices  because  of  the  number  of  devices  alone.  Instead,  device 
reliability  becomes  a function  of  physical  connections  (e.g.,  solder  joints)  required  to  electrically 
connect  the  device  in  the  subsystem  (PE).  Here  the  single-chip,  and  hence  the  single  package, 
usually  has  a slight  advantage  because  of  overall  pin-out  reductions.  However,  this  advantage  is 
considered  minor  and  is  more  than  offset  by  the  economic  advantages  afforded  by  the 
multi-device  approach. 

The  initial  considerations  of  single-chip  versus  multi-chip  BIU  implementation  are  one  facet 
of  the  overall  physical  partitioning  approach,  it  is  recommended  that  the  physical  partitioning  of 
the  BIU  produce  a BIU  device,  or  set  of  devices,  which  is  not  tied  to  any  one  particular  bus 
interface  technology/technique.  This  suggests  that  all  functional  elements  of  the  BIU  related  to 
unique  electrical  interface  or  “language”  interface  with  the  TDM  buses  should  be  physically 
segregated  from  the  basic  BIU  functions  for  the  cost-effective  purpose  of  device  (and  PE) 
flexibility  and  the  reduced  degree  of  device  obsolescence.  Thus,  if  the  "standard”  DP/M  BIU  is 
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to  withstand  likely  future  bus  technology/technique  modifications  (e.g.,  the  replacement  of  the 
bus  common  cable  with  fiber  optics),  it  should  be  physically  relieved  of  the  bus  driver/receiver 
and  bus  language  translation  functional  elements.  Furthe'  implementation  considerations  should 
attempt  at  least  a rough-guess  prediction  of  commercially  applicable  devices  for  the  expected 
high  volume  microcomputer/microprocessor  market  in  the  DP/M  time  frame.  This  area  can  have 
a marked  impact  on  device  cost  if  commercial  market  compatibility  is  achieved.  Finally, 
consideration  should  also  be  given  to  the  implementation  time  frame  desired  for  the  DP/M. 
Optimally,  the  functional  design  should  not  constrain  implementation  of  the  BIU  in  either  LSI 
approach,  and  should  allow  a reasonable,  relatively  near-term  (perhaps  interim),  implementation 
realization.  Therefore,  it  is  recommended  that  the  BIU  design  should  accommodate  and 
emphasize  multichip  implementation  in  accordance  with  the  guidelines  discussed  previously. 
Thus,  the  BIU  device  partitioning  shown  in  Figure  86  is  proposed.  The  rationale  supporting  this 
particular  partitioning  is  presented  in  the  subsequent  paragraphs. 

The  proposed  multichip  BIU  implementation  shown  in  Figure  86  is  the  result  of 
incorporating  all  the  previously  outlined  partitioning  considerations.  The  design  will  require  a 
maximum  of  four  device  types  for  realization  of  the  modular  BIU  LSI  implementation:  one  of 
these  device  types  is  a non-LSI  (SSI  complexity)  line  driver/receiver  which  may  be  satisfied  with 
existing  catalog  parts. 

The  proposed  partitioning  first  requires  segregation  of  the  Global  and  Local  bus  interface 
logic  into  two  physically  separate  but  identical  devices  (i.e.,  one  common  part  type)  referred  to 
as  the  Bus  Interface  Logic  Unit  (BILU).  This  is  permitted  since  the  functional  BIU  design 
requires  nearly  identical  operation  by  each  separate  bus  interface.  There  are,  however,  several 
minor  differences  in  Global/Local  operation  which  may  be  handled  by  a “personality” 
device-input-signal  technique.  This  concept  of  the  standard  BILU  device  permits  the  common 
implementation  to  perform  one  of  two  specific  sets  of  operations  based  on  the  binary  state  of  a 
bus  characterization  signal  connected  to  one  of  the  device  I/O  pins.  The  different  operations 
which  must  be  distinguished  within  the  BILU  are: 

Both  the  glob  ' and  local  interfaces  respond  to  the  same  type  of  I/O  instruction 
commanus,  but  each  must  be  addressed  (via  the  I/O  instruction  Command 
Address  Word)  with  a different  command  address:  thus  the  command  decode 
logic  must  decode  different  command  addresses  for  global  and  local  opera- 
tions. 

The  Input  Message  Queue  Pointer  (IQP)  in  the  global  interface  must  address  a 
different  region  (queue)  in  PE  memory  than  that  addressed  by  the  local  IQP. 

Primary-level  interrupt  control/interfacing  is  different  for  the  global/local  interfices 
(e.g.,  interrupt  trap  address  generation). 

The  handling  of  these  differences  within  a common  device  by  external  hardwired  control 
requires  very  little  additional  hardware  complexity  introduced  into  the  common  BILU  device 
implementation.  This  technique  does  allow  the  usage  of  a common  part  type  to  implement  both 
global  and  local  interface  functions,  a characteristic  which  is  important  in  reducing  BIU  hardware 
costs  and  permitting  a near-term  implementation  realization  because  of  greatly  reduced  device 
complexity.  In  addition,  it  allows  PE  configuration  with  or  without  both  global  and  local  bus 
facilities,  depending  on  different  application  requirements.  Tne  BILU  device  will  require  an 
estimated  complexity  of  2,000  gates  and  may  be  packaged  in  a standard  48-pin  package.  With 
!JL  implementation,  this  device  will  dissipate  606  mW  of  power.  The  BILU  is  by  far  the  most 
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Figure  86.  Multi-Device  BIU  Partitioning 


complex  B1U  device,  but  its  complexity  is  within  the  expected  near-term  realm  of  IJL 
technology.  An  I/O  signal  definition  of  the  B1LU  device  is  shown  in  Figure  87. 

The  suggested  partitioning  of  the  B1U  removes  all  functions  associa’ed  with  “language 
translation"  between  the  Global/Local  buses  and  the  PE.  The  unique  devire  which  performs 
these  functions  is  referred  to  as  the  Bus  Interface  Translation  Unit  (BITU).  This  device  is 
effectively  inserted  in  the  serial  data  channel  path  between  a BILU  and  the  bus  with  which  it 
communicates.  It  is  important  that  the  interface  between  these  two  BIU  devices  should  represent 
a “standardizable"  serial  interface  to  accommodate  various  system  bus  language  requirements 
with  the  changing  of  only  one  part  type,  the  BITU.  The  BITU  device  may  be  housed  in  a 
standard  14-pin  package  with  a complexity  of  approximately  100  gates.  With  I2L  implemen- 
tation, expected  power  dissipation  is  only  62  mW.  An  I/O  signal  definition  of  this  device  is 
shown  in  Figure  88. 

The  remaining  BIU  device  is  one  which  is  required  to  manage  the  DP/M  redundant  Global 
buses.  This  Redundant  Bus  Management  Unit  (RBMU)  is  functionally  placed  between  the  BILU 
and  the  redundant  bus  BITUs.  An  alternate  approach  is  to  place  the  RBMU  between  the  bus 
drivers/receivers  for  both  buses  and  a single  BITU.  This  approach  would  require  one  less  BITU 
but  would  require  the  inclusion  of  bus  reception  translation  (e.g.,  biphase-level  to  NRZ  decoding) 
logic  in  the  RBMU  to  allow  switchover  command  decode.  T..is  capability  inherently  exists  in  the 
BITU,  and,  moreover,  is  responsible  for  a large  majority  oi  fie  BITU  complexity  (biphase-level 
encoding  is  much  simpler  to  implement  than  asynchronous  biphase  decoding).  The  partitioning 
approach  suggested  requires  a simpler  (less  complex)  RBMU  device  at  the  expense  of  an  added 
BITU  device  in  the  BIU. 

The  RBMU  may  be  implemented  in  a single  40-pin  device  requiring  290  gates.  With  I2L 
implementation,  anticipated  power  dissipation  of  this  device  is  41  mW.  An  I/O  signal  definition 
of  this  device  is  shown  in  Figure  89.  An  alternate  and  perhaps  more  desirable  partitioning 
approach  allows  packaging  of  the  unique  RBMU  functions  in  a smaller,  standard  20-pin  package 
An  auxiliary  device,  a standard  available  quadruple  2-to-l  multiplexer,  is  required  to  complete 
the  RBMU  function.  This  alternate  partitioning  is  shown  in  Figure  90. 

The  Bus  Master  Interface  (BMI)  device  shown  in  Figure  36  incorporates  all  functional 
elements  related  to  interfacing  the  BIU  with  the  PE  internal  bus  (I-BUS)  and  thus,  with  the 
processor  and  memory  units.  The  BMI  device  complexity  is  relatively  low;  the  prime  motivation 
behind  its  inception  is  the  pin-out  relief  it  offers  the  BILU,  allowing  the  BILU  to  be  packaged  in 
a commercially  compatible  package  size  (48  pins).  If  further  detailed  investigation  of  BILU 
pin-out  requirements  al'ow,  the  BMI  functions  may  be  included  in  the  BILU.  assuming  the 
resulting  density  is  attainable  in  a single  device.  The  BMI  functional  device  implementation  is 
discussed  in  Subsection  VI.C.4  on  input/output  interface  unit  (IOIU)  device  partitioning. 

In  summary,  the  BIU  partitioning  approach  presented  above  stresses  near-term  LSI 
implementation  compatibility  with  minimized  device  cost  and  allows  gradual  merging  of  multiple 
device  functions  into  single  devices  as  LSI  technology  progresses,  if  such  measures  are  deemed 
cost-effective  and  desirable.  In  contrast,  implementation  of  the  entire  BIU  (excluding  line 
drivers/receivers)  within  a single  LSI  device,  as  shown  ».i  Figure  91,  would  require  a device 
complexity  of  approximately  4,600  gates  and  55  I/O  signal  pinouts.  A nonstandard  LSI  package 
would  have  to  be  used  and  a rather  optimistic  furthering  of  present  technology  would  be 
required  to  achieve  the  required  density.  Both  are  very  costly,  in  dollars  and  risk.  The 
multi-device  BIU  partitioning  approach  is  presented  as  the  most  flexible  and  cost-effective 
foreseeable  near-term  solution  to  LSI  implementation  of  the  BIU  function. 
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Figure  87,  But  Interface  Logic  Unit  (BITU)  Device  Attributes 
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Figure  88.  Bus  Interface  Translation  Unit  (BITU)  Device  Attributes 
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Figure  89.  Redundant  Bus  Management  Unit  (RBMU)  Device  Attributes 
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Figure  90.  lUduMlMt  Bat  Mmigunihl  Unit  (RBMli)  Device  Impkwemutio*  AhwMtir  t 


(BRQ) 


4.  Input  Output  Interface  Unit 


Initial  investigations  into  physical  partitioning  and  LSI  device  packaging  reveal  that  the 
physical  implementation  ol  the  IOIU  will  be  driven  and  constrained  primarily  by  pinout  (I/O 
signal)  considerations  rather  than  device  complexity  concerns.  As  is  the  case  with  any  parallel 
I O interlace,  more  pinouts  ire  always  required  than  are  available.  This  truism  holds  in  the  case 
of  the  IOII1.  A relatively  large  number  of  pinouts  (7|)  will  be  required  to  implement  all  IOIU 
functions  with  a single  1 SI  device,  even  though  a reasonable  device  c;mplexity  of  approximately 
1.300  gates  is  required.  If  a single-device  implementation  is  desired,  then  some  concession  to 
increased  packaging  costs  must  be  endured  because  of  the  nonstandard  pinout  requirement  (i.e., 
custom  packaging). 

To  determine  the  advantages  afforded  by  the  use*  of  standard-package  LSI  parts,  a 
preliminary  multichip  partitioning  was  investigated.  The  initial  approach  was  to  relieve  the  single 
IOII'  device  of  the  pinout  burden  imposed  by  the  interface  with  the  16  I'O  data  lines  by 
buttering  these  signals  with  separate  Input  Output  Data  Interlace  (IODI)  devices.  The  IOD1 
devices  provide  an  output  data  storage  capability  and  line  driver  receiver  compatibility  between 
the  I’l  l-BLS  and  the  external  I ()  data  lines.  Remaining  IOIU  functions  were  retained  in  a single 
Input  Output  Logic  Unit  llOLU)  device,  however,  this  partitioning  was  still  unsatisfactory,  since 
remaining  IOLU  pinout  requirements  were  55  pins.  With  a standard  device,  dual  in-line  packaging 
goal  of  48  pins  maximum,  further  partitioning  techniques  were  sought.  Removal  of  the  ancillary 
support  functions  of  PI  tnitiali/ation  control  and  PI  clock  control  allows  implementation  of  the 
remaining,  basic  IOIU  functions  in  a 48-pin  device  with  a complexity  of  950  gates.  This  level  of 
IOLU  device  implementation  is  shown  in  Figure  ‘>2.  The  segregated  support  functions  would  be 
implemented  with  standard,  available  integrated  circuit  tIO  devices.  Using  this  abbreviated  IOLU 
approach,  the  physical  partitioning  of  the  overall  IOIU  functional  design  is  shown  in  Figure  93. 

With  the  realization  of  the  partitioning  constraints  imposed  by  pinout  requirements  alone 
(with  respect  to  the  use  of  standard  1C  packaging  techniques),  further  investigation  into  the 
advantages  of  a multichip  implementation  of  the  IOLU  functions  was  undertaken.  This 
investigation  revealed  that  the  development  of  an  "I'O  device  family”  could  yield  many  benefits 
with  respect  to  DP  N1.  The  unified  bus  stmeture  of  the  PE  design  both  facilitates  and  encourages 
the  use  of  modula  . building-block  I O construction.  Of  primary  benefit  are  the  following  three 
factors  afforded  by  a "family"  structure  ot  common  I O building-block  device  types: 

• Diverse  application  flexibility  Individual  I O characteristics,  which  are  typically  the 
nongeneral  and  most  difficult  to  standardize  portions  of  any  system  design,  are 
easily  modified  for  purposes  of  system  reconfiguration  or  extended  usage  adaptation. 

• Commercial  compatibility  A gener.di/ed  family  of  building-block  I'O  interface 
devices  is  directly  compatible  with  commercial  multiple  application  concepts.  Since 
most,  it  not  all.  of  the  IOLU  functions  defined  for  DP  M could  be  considered  basic 
for  a maturity  of  applications,  a physical  partitioning  of  these  functions  which 
allows  variable  I O configurations  could  be  significant.  If  the  DP'M  PH  is  to  become 
a cost-effective  systen  building-block  device,  a primary  design  goal  should  be  the 
establishment  ol  parts  commonality  with  a standard  commercial  production  base. 
Proper  structuring  and  partitioning  of  the  input 'output  unit  functional  design  could 
be  a key  factor  in  the  achievement  of  this  goal  With..i  the  vein  of  the  partitioning 
philosophy,  a functional  family  partitioning  of  the  IOLU  functions  was  developed. 
The  various  device  partitionings  and  the  interconnection  of  these  devices  into  the 
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Figure  92.  Input/Output  Logic  Unit  (tOLU)  Device  Attributes 


EXTERNAL.  DEVICE 


Figure  93.  Input/Output  Interface  Unit  Physical  Partitioning 


DP/M  10LU  are  shown  in  Figure  94.  The  individual  functional  devices  are  discussed 
below.  Several  functional  features  are  included  in  the  suggested  family  of  devices  not 
representative  of  the  DP/M  application  per  se;  however,  these  features  have  been 
included  (at  insignificant  hardware  complexity  expense)  to  enhance  applicability  in  a 
more  generalized  functional  environment. 

The  Autonomous  Transfer  Channel  (ATC)  interface  provides  an  autonomous,  block- 
oriented  UO  data  channel  which  possesses  the  functional  characteristics  described  in  Section  V. 
This  interface  is  partitioned  into  two  discrete  LSI  devices:  an  Autonomous  Transfer  Control 
Logic  (ATCL)  device  and  an  Autonomous  Transfer  Control  Register  (ATCR)  device.  The  ATCL 
device  performs  all  data  channel  controller  functions;  the  ATCR  provides  the  necessary  register 
elements  required  for  data  channel  operation.  The  two-chip  partitioning  is  dictated  by  pinout 
requirements  to  allow  the  use  of  a standard  dual  in-line  packages.  Input/output  signals  and 
physical  characteristics  of  the  ATCL  and  ATCR  devices  are  shown  in  Figures  95  and  96. 

The  IODI  device  provides  data  buffering  between  the  external  I/O  data  lines  and  the  PE 
internal  I-BUS.  An  output  data  holding  register  is  provided  in  the  IODI  to  allow  asynchronous 
transfers  of  data  from  the  PE  memory  to  external  devices.  Input/output  signals  and  physical 
characteristics  of  the  IODI  are  shown  in  Figure  97. 

The  BMI  device  is  responsible  for  providing  interface  compatibility  between  a master 
device  and  the  PE  l-BUS.  The  primary  functions  of  the  BMI  are  I-BUS  control  protocol 
compatibility  and  data  transfer  timing  for  either  single-word  or  data-block  transfer  modes 
between  devices  connected  to  the  PE  I-BUS.  For  system  design  convenience,  the  BMI  also 
provides  transfer  time-out  determination  with  hardware-selectable  timing.  The  BMI  device  serves 
the  same  function  as  the  IBIU  device  mentioned  in  the  previous  BIU  partitioning  investigation. 
Input/output  signals  and  physical  characteristics  of  the  BMI  device  are  shown  in  Figure  98. 

The  Bus  Slave  Interface  (BSI)  device  provides  a straightforward  and  convenient  means  of 
interfacing  slave  I/O  devices  to  the  Pc  via  the  I-BUS.  The  BSI  can  support  either  responsive  or 
nonresponsive  communication  with  these  devices.  The  BSI  provides  address  decode  and  read/ 
write  operation  determination  associated  with  slave  device  data  transfer  operations.  The  BSI 
allows  selectable  (hardwired)  address  definition  for  the  slave  device  which  it  interfaces  and 
selectable  timing  of  slave  device  data  transfer  control  signals.  These  selectable  characteristics 
permit  the  BSI  device  to  accommodate  virtually  any  type  of  passive  I/O  device  includiig  most 
conventional  semiconductor  memories.  An  I/O  signal  level  description  of  the  BSI  device  is  given 
in  Figure  99. 

Functionally,  the  BSI  is  used  to  achieve  programmed  I/O  operations  between  the  processor 
and  I/O  devices  where  one  word  of  data  is  transferred  to/from  the  device  per  I/O  instruction 
execution.  In  DP/M  applications  where  this  mode  of  I/O  data  transfer  is  desirable,  programmed 
I/O  may  be  achieved  by  direct  connection  with  the  associated  I/O  device  (and  BSI  device)  via 
the  I-BUS,  as  illustrated  in  Figure  94. 

The  Interrupt  Interface  (INTI)  device  provides  a flexible  interrupt  stimulus  interface  to  the 
PF.  via  the  I-BUS  interrupt-associated  signal  lines.  Basic  INTI  functions  include: 

• Interrupt  request  and  acknowledge  logic/timing 

• Interrupt  priority  resolution 
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^ADDRESS  (ADDR)  16j 


^DATA 

, — y 

(DATA)  16^ 

MASTER 

CLOCK 

(MCLK) 

1 

POWER 

(5VDC) 

GROUND 

(GND) 

-rf 

1^ 

ATCR 


REGISTER 

CONTROL 

(RCTL)1 

END-OF- 
l BLOCK 

(EOBKli 

AUTONOMOUS 

TRANSFER 

CONTROLLER 

LOGIC 

(ATCL) 


FUNCTIONAL  REGISTERS 
(EACH  16-BITS  IN  LENGTH) 

BUFFER  ADDRESS  REGISTER  (BAR)  40  PINS  (40  PIN  PKG) 

BUFFER  LENGTH  REGISTER  (BLR)  755  GATES 

LINK  ADDRESS  HOLDING  REGISTER  (LAHR)  352  MILLIWATTS* 

INTERRUPT  TRAP  ADDRESS  REGISTER  (ITAR)  . , 

•ASSUMES  lzL  TECHNOLOGY 


REGISTER  CONTROL  ENCODED  FUNCTIONS: 


PROGRAM- f 
CONTROLLED 
READ 

PROGRAM- ? 
CONTROLLED < 
LOAOS  L 


MEMORY J 
READS  | 


MEMORY  > 
WRITES 


RCO 

RC1 

RC2 

RC3 

ACTION 

0 0 0 0 

DO  NOTHING 

0 0 0 1 

BAR  P DATA 

0 0 10 

BLR  -P  DATA 

0 0 11 

LAHR  P DATA 

0 10  0 

DATA  p ITAR 

0 10  1 

DATA  p BAR 

0 110 

BAR  » ADDR 

0 111 

DATA  pBAR,  BAR  _*ADDR 

10  0 0 

DATA  -P  BLR,  BAR  -pADDR,  BAR+  1-p BAR 

10  0 1 

DATA  (08-10)  — P BLR , BAR  -PADDR,  BAR+1-P  BAR 

10  10 

DATA  - ■ P LAHR,  BAR-p ADDR.  BAR+  1-p  BAR 

10  11 

DATA  P LAHR  , BAR-p  ADDR.  LAHR  -p  BAR 

110  0 

BLR— 1 P BLR,  BAR  -PADDR,  BAR+  1-p  BAR 

110  1 

DATA  P BLR,  BAR-f  1 -p  BAR 

1110 

LAHR  PBAR 

1111 

UNDEFINED 

Fir*re  96.  Autonomous  Transfer  Controler  Registers  (ATCR)  Device  Attributes 
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l-SUS< 


DATA  IN  (n-n  +3) 


^DATA  (n-*n  + 3)(DATA)5_ 

IODI 

Jy  (DIN) 

• /• 

FOWER  (5  VDC)  1/. 

DATA  OUT  (n-n  + 3) 
4 y (DOUT) 

/ * 

ENABLE  DATA  IN 

J ^(ENDI) 

/ 9 

GROUND  (GND) 

LATCH  DATA  OUT 
J y-(LDO) 

•/ 

} EXTERNAL 
DEVICE 


> 

AUTONOMOUS 
v TRANSFER 
CONTROLLER 
* LOGIC  (A  TCL) 


16  PINS  (16  PIN  PKG.) 

34  GATES 

100  MILLIWATTS* 

•ASSUMES  LOW  POWER  SCHOTTKY 
TECHNOLOGY 


! 


FUNCTIONAL  LOGIC  DESCRIPTION 


L_ 


Figure  97.  Input/Outpul  Data  Interface  (lODi!  Device  Atttibutes 


• Programmable  interrupt  mask  (1-bit) 

• Programmable  interrupt  stimulus  reset  control 

liiput/output  signals  and  physical  characteristics  of  the  INTI  device  are  shown  in  Figure  100.  The 
Programmable  Interval  Timer  (PIT)  function  described  in  Section  V can  be  readily  implemented 
with  a single  low-complexity  LSI  device.  To  permit  PIT  compatibility  with  a wide  variety  of 
applications,  the  suggested  single  LSI  device  design  possesses  some  additional  features  above  and 

beyond  those  required  for  the  DP'M  avionics  application  investigated.  These  additional  features 

are: 

• Timer  resolution  is  programmable  to  permit  a selectable  count  period  of 
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L 


(BRQ) 


Figure  98.  Buc  Muter  Interface  (BMI)  Device  Attributes 


r 


L 


Figure  99.  Bus  Stove  interface  (BSD  Device  Attributes 


Figure  100.  Interrupt  Interface  (INTI)  Drvjce  Attributes 


where  ff|k  is  the  input  clock  frequency. 

• Additional  control  logic  allows  hardwired  selection  ot  device  function  as  a pro- 
grammable interval  timer  or  real-time-clock  ("‘time-tick"  source)  and  allows  cascading 
of  PIT  devices  to  achieve  larger  time  interval  capabilities. 

These  additional  features  will  require  increased  device  complexity,  but  the  magnitude  of  the 
increase  is  not  considered  significant  with  respect  to  added  device  cost.  An  I'O  signal  definition 
of  the  suggested  PIT  device  is  given  in  figure  101. 

The  above  "device  family"  partitioning  results  in  a set  ot  low-risk  • omplexitv  I SI  .tr>'  low 
complexity  (MSI)  devices.  The  MSI  caliber  devices  (i.e..  the  IODB.  BMI.  BSI.  ami  IM'I  (icvuest 
allow  implementation  in  a standard,  conventional,  non-LSI  technology,  such  as  currentK  fr-.iier 
ating  low-power  Schottky  bipolar  technology,  without  an  overbearing  increase  in  power  dissi- 
pation while  enhancing  overall  device  applicability  because  of  improved  device  performance 
capabilities  and  potentially  decreasing  device  costs  associated  with  development  and  production 

Remaining  IOIU  functions  not  provided  in  the  above  family  of  devices  arc*  PL  initialization 
control  and  PE  clock  control.  Since  both  of  these  PF  support  functions  may  lx*  straightforwardly 
implemented  with  a few  standard  (catalog)  integrated  circuit  part  types.  the  fabrication  of 
special,  unique  LSI  devices  to  be  used  for  their  implementation  is  not  considered  cost  et  feet  isl- 
and, thus,  is  not  recommended. 

The  PE  initialization  function  requires  a 32-word  by  16-bit  ROM  foi  a bootstrap  program 
memory  plus  the  control  logic  required  to  sequence  memory  address  steering  to  the  bootstrap 
program  address.  From  a physical  viewpoint,  the  bootstrap  ROM  (probably  two  l(  deuces)  may 
be  considered  and  partitioned  as  part  of  the  PE  memory.  The  bootstrap  program  Meer.ng 
functions  may  be  implemented  with  a few  available  small-scale  integration  (SSI)  1C  deuce*. 

The  clock  control  function  requires  the  necessary  counter  circuitry  to  divide  uown  an 
externally-sourced  “free"  clock  frequency  to  the  basic  clock  frequency  usable  bv  the  PL  This 
PE  clock  must  be  gated  in  response  to  a maintenance-functior  -tel.iU d clock  control  Mgn.il  to 
provide  "'JN/STOP  modes  of  operation.  To  prevent  the  PL  design  Ou'ictionjl  and  phs-uall 
from  • v ning  tied  to  a given  technology,  it  is  recommended  that  all  PI  clock  trcqu-iuy 
deriva,  1 "laments  be  physically  partitioned  outside  the  basic  PL.  By  placing  these  deuces 
external  to  the  PE  proper,  improvements  in  PE.  performance  through  technology  advancement  or 
alteration  may  he  accommodated  without  requiring  redesign  (relay  out  I ot  any  PI  LSI  devices 
An  analogous  consideration  applies  to  the  clock  gating  function  as  well,  because  of  possible 
unique  maintenance  function  clock  control  requirements,  it  is  recommended  that  all  clock 
control  functions  be  segregated  from  IOIU  LSI  device  implementation,  regardless  of  whether  the 
single-device  or  multi-device  IOIU  partitioning  app-oach  in  accepted. 

The  briefly  discussed  family  of  I/O  devices  and  resultant  101 11  physical  partitioning  are 
deemed  to  possess  the  functional  and  physical  properties  representative  o!  a trulv  comprehensive., 
universally  applicable  I/O  buiLing-block  structure.  These  devices  allow  basic  interfacing  with 
many  I/O  device  types  and  offer  an  expandable  "pay-as-you-go"  system  design  using  the  DP  M 
PE.  It  bears  repeating,  however  that  this  particular  device  partitioning  approach  is  not  required 
entirely  for  the  DP/M  application  per  se.  hut  it  affords  the  cost-etlective  virtues  ot  system  deuce 
flexibility  and  likely  commercial  parts  base  compatibility,  factors  to  be  weighed  with  overall 
DP/M  PE  design  goals.  The  use*  ot  commercially  available  part  types  and  the  promise-  ol 
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Figure  101.  Programmable  Interval  Timer  (PIT)  Device  Attribute* 


ih .n  t iim  implementation  with  overall  reduced  LSI  parts  costs  (simpler  devices)  justifiably  ^uidc 
tin-  lOlU  design  toward  the  multi-device  partitioning  described  herein. 

fc\  COST  PROJECTIONS 

It  is  admittedly  difficult  to  make  accurate  cost  projections  as  far  into  the  future  as  1980. 
flic  cost  figures  presented  herein  are  for  production  units  only  and  av  ume  a quant  it  y order  of 
5.000  units.  They  do  not  include  any  design,  development  and/or  ’.ualificatton  costs  nor  any 
factors  for  inflation.  The  basic  factors  that  have  Ircm  u.ed  for  estimating  arc  that  a high-volume 
standard-production,  dynamic  NMOS  memory  cell  will  be  used,  it  will  cost  about  I cent/bit:  and 
the  processor  will  cost  about  I cent/gate.  Both  of  these  estimates  are  based  on  commercial  grade 
parts  (0°  to  70°C,  plastic  package).  Because  the  memory  controller,  the  I/O  interface,  and  the 
Inis  interface  arc  not  as  universally  applicable,  they  are  expected  to  have  a lower  volume 
production.  It  will  he  assumed  that  they  will  cost  twice  as  much  per  gate  (i.e.,  2 cents/gate),  l-r* 
comparative  purposes,  projections  have  been  worked  up  for  three  different  versions  ol  the  DP/M 
PI:  (Table  23).  All  cases  assume  an  external  power  source. 

I.  Commercial  Microcomputer 

The  commercial  microcomputer  version  uses  commercial  plastic  parts  (0°  lo  +70  C,  no 
device  acceptance  test  burn-in),  a 4K  word  memory  without  parity  or  write  protect,  no  bus 
interface  unit,  and  a two-sided  printed  wiring  board  (PWB)  with  a one-piece  (edge)  connector. 


TABLE  23.  PROJECTED  1980  DP/M  PE  COSTS 


Commercial 

Commercial 

Military 

Microcomputer 

Grade  DP/M  PE 

Grade  DP/M 

Tcmperatuic  range 

0“  to  +70°C 

0J  to  +70 °C 

55DC  to  +1 

Burn-in 

No 

No 

Yes 

Packaging  (DIP) 

Plastic 

Plastic 

Ceramic 

Memory: 

Size  ( 1024s)  words 

4 

n 

Parity 

No 

Yes 

Yes 

Write  protect 

No 

Yes 

Yes 

Connector  ( PWB  > 

one  piece* 

one-piece* 

iwo-piecc 

Cost  . . . _ 

Piocessor 

S 40 

S 40 

S200 

Memory 

h4 

144 

720 

Memory  controller 

5b 

15 

75 

I/O  interface 

JC 

30 

150 

Bus  interface  unit 

too 

500 

PWB,  connector  and  assembly 

20 

20 

too 

Total 

SI  5') 

S349 

SI. 745 

* PWB  edge  connector 
Refresh  only 


I Ins  yields  a “ban*  bones"  lb-bit  microcomputer  for  under  S20G,  and  these  figures  are  somewhat 
Imvor  t ban  projections  made  by  others.  '-or  example,  Herman  Schmid  speaks  of  lb-bit  CPUs  for 
'SMI  ami  lb-bit  microprocessors'  (electronics  only)  for  S200  both  in  quantity  and  in  1980.  As 
was  anticipated,  the  memory  tends  to  dominate,  amounting  to  almost  half  the  cost  of  the 
microcomputer.  It  is  noteworthy  that  this  cost  corresponds  to  between  _ 10-to-l  and  20-to-l 
reduction  in  cost  over  contemporary  minicomputers  which  have  the  same  level  ot  processing 
capabilitv. 


Commercial  Grade  DP/M  PE 


I lie  next  step  in  the  cost  projection  is  to  start  adding  features  to  the  “bare  bones" 
microcomputer  to  upgrade  it  to  a DP/M  PH.  This  involves  doubling  the  memory  (already  the 
most  expensive  item),  adding  parity  and  write  protect  to  it,  and  finally  adding  the  BIU  which  is 
more  complex  than  the  processor  (CPU).  These  additions  more  than  double  the  cost  of  the 
microprocessor  and  bring  its  cost  for  a commercial  grade  DP/M  up  to  between  $300  and  $400. 
I'ltese  figures  are  well  in  line  with  the  figures  projected  by  Honeywell  in  their  DP/M  study2 
especially  when  considering  that  the  memory  has  been  doubled  in  si/.;*  to  allow  better  use  of  the 
processing  power  of  the  PH.  Again  these  costs  are  between  a 10-to-l  and  a 20-to-l  reduction 
over  what  one  would  currently  pay  for  a minicomputer  with  these  capabilities. 

.V  -Military  Grade  Dl’/M  PH. 

The  biggest  single  factors  in  the  cost  of  the  l)P/M  PH  are  the  military  environmental  and 
reliability  requirements.  All  devices  must  be  premium  parts  which  can  operate  over  the  full 
military  temperature  range  of  55  ’ to  + I25“C.  These  are  the  requirements  for  components  to  be 
used  in  equipment  wine1*  must  meet  i MIL-H-5400.  Class  2.  environment.  This  specification 
requires  equipment  to  operate  continuously  at  51"  to  -* 7 1 ° C with  intermittent  (30-minute) 
operation  at  -t95°C.  This  latter  condition  would  only  allow  a 30" C thermal  gradient  between  the 
external  i KU  environment  and  the  semiconductor  devices  inside  the  equipment.  In  addition,  the 
reliability  requirements  dictate  many  in-process  inspections,  hermetically  sealed  ceramic  packages 
rather  than  plastic,  and  usually  an  extensive  burn-in  and  testing  cycle.  These  additional  require- 
ments normally  increase  the  component  cost  by  5 to  I.  Other  (actors  that  increase  the  PF.  cosl 
arc  the  additional  PWB  fabrication  inspections  and  controls,  as  well  as  the  requirement  for 
two-piece  military-qualified  connectuis.  These  factor-  send  the  cost  of  the  DP/M  PE  into  the 
$1,500  t<>  $2,000  range.  While  (Ids  ligurc  may  sewn  .ugh.  it  is  still  0.05  to  0.1  the  cost  of  most 
current  mildary-qualified  computers.  This  5-to-l  premium  for  military-qualified  semiconductor 
components  and  equipments  has  to  do  with  the  lower  volume  of  military  procurements  coupled 
with  the  cost  of  the  added  processing  steps  and  the  requirement  for  premium  parts. 

4.  ( ost  Conclusion 

The  DIVM  PH.  will  allow  between  a 10-to-l  and  a 20-to-l  decrease  in  the  cost  of 
computers  for  the  military  avionics  application.  It  will  not  allow  the  100-to-i  decrease  in  cost 
that  some  have  projected.  The  reason  for  this  5-to-l  difference  is  that  the  military  requirements 
for  operating  temperature  and  reliability  are  much  more  severe  than  the  commercial  require- 
ments. If  the  commercial  requirements  became  more  like  the  military,  or  vice  versa,  this 
difference  would  disappear.  An  example  ol  a commercial  application  that  has  a military-like 
requ'-ement  is  the  automobile.  Similar  high-volume,  rugged  applications  like  this  could  bring  the 
military-grade  cost  down  to  nearly  the  same  as  the  commercial-grade  cost. 


1 1 ler  Di.i n Schmid,  "MnnoliMih'  IX  / m e'e . r - t nt'iiuih  r f)rsh:n,  Octnhei  1 07*1. 
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SECTION  VII 

FUNCTIONAL  SIMULATION  SYSTEM 

A.  SECTION  OVERVIEW 

This  section  is  concerned  with  the  Functional  Simulation  Task  (SOW  4.1).  In  particular, 
this  section  describes  tasks  to  be  pertormed.  design  approach  taken,  design  results,  and  key 
features  of  the  resulting  simulation  system. 

B.  INTRODUCTION 

Within  the  context  of  the  DP/M  s> stein  concept,  the  objective  was  to  design,  develop,  and 
use  the  necessary  simulation  and  analysis  tools  adequate  for  evaluating  the  major  design 
considerations  of  a DP/M  network.  The  Simulation  System  is  divided  into  two  separate 
simulators:  the  System  Network  Simulator  and  the  Processing  Hemcnt  Simulator.  Each  simulator 
will  be  discussed  in  detail  in  the  following  paragraphs,  how-ever.  a general  description  of  each  will 
be  included  at  this  time.  The  System  Network  Simulator  is  a high-level  traffic  simulator  whose 
main  function  is  to  study  the  effects  ot  different  topological  network  organizations.  The 
Processing  Element  Simulator  is  a more  detailed  simulator  concerned  with  the  internal 
performance  of  a single  processing  element.  The  PE.  Simulator  actually  simulates  functions 
performed  as  each  instruction  is  executed  by  the  Processor. 

The  nature  of  the  DP  M architecture  requires  certain  capabilities  of  the  eventual 
Functional  Simulation  System.  The  design  simulator  approach  wac-  strongly  influenced  by  the 
characteristics  of  the  DP/M  system  to  be  simulated.  In  particular  the  DP/M  system  consisted  of 
a network  ot  autonomous  processing  elements  connected  by  two  levels  of  time-division- 
multiplexed  buses.  Control  of  the  buses  was  distributed  as  well  as  some  portion  of  the  executive 
control.  The  Processing  Element  itself  was  similarly  constructed  with  processor,  memory.  I/O. 
and  bus  interfaces  all  communicating  over  an  internal  bus.  In  addition,  there  were  requirements 
for  variable  levels  of  simulation  detail.  Some  events  needed  to  be  modeled  at  the  register  and/or 
clock  level,  while  other  events  were  sufficiently  modeled  at  a higher  functional  level.  For 
example,  the  Bus  Interface  Unit  was  modeled  at  the  detailed  hardware  register  level  in  the 
Processing  Element  Simulator  but  the  bus  was  modeled  at  the  functional  level  in  the  System 
Network  .simulator.  To  satisfy  these  goals,  the  Functional  Simulation  System  was  structured  as  a 
discrete  event-oriented  simulation  system  built  around  a nucleus  of  common  model  independent 
utility  routines.  The  model  independent  routines  are  the  tools  by  which  the  actual  simulator  is 
constructed.  The  model  independent  routines  by  themselves  are  not  a simulator,  but  are  used  to 
build  tht  different  simulators.  The  simulation  control  is  implicit  within  the  basic  simulator  and 
explicit  control  of  the  events  is  not  required.  The  use  of  a common  simulation  language  allows  a 
uniform  method  of  development,  implementation  and  modification.  The  two  simulators  are 
functionally  compatible,  allowing  tor  interaction  and  interchange  of  data. 

Key  features  of  the  simulation  tools  developed  include  a common  uniform  structure 
written  in  ANS  FORTRAN  that  also  permitted  ease  of  modification  and  future  growth.  The 
System  Network  Simulator  can  be  considered  to  be  a continuation  of  capability.  Although  the 
System  Network  and  Processing  Element  Simulators  are  logically  separated  for  the  purpose  of 
discussion,  they  are  actually  the  same  type  of  simulator  with  different  events  modeled  to  a 
particular  level  of  detail.  Each  has  the  capability  to  model  variable  time  quantum  events  and 


variable  levels  ot  detail  The  must  valuable  feature  hv  far  though,  is  the  extensibility  of  the 
'"""I-"'1'"  N>',h*m  lr,,m  !,u*  hardware  design  on  through  the  software  ileveloftineiit  and 

'!*  ">  integration  l or  example,  the  models  for  Hie  avionic  software  within  the  System  Network 
Siinnlaloi  m.iy  I'e  replaced  by  higher  and  higher  fidelity  models  until  the  model  represents  the 
actual  •'■M.'inblv  language  that  then  may  be  simulated  by  the  Processing  Flement  Simulator.  In 
the  eouise  of  these  evolutionary  simulations,  the  system  under  development  goes  through  a 
met.iiiio: pliosis  in  the  sense  that  one  starts  with  the  ••h-level  simulation  of  the  entire  system, 
iiiadiially.  high-level  models  of  system  components  ,,re  one-hy*one  replaced  with  their  more 
detailed  counterparts.  Once  functional  simulation  has  been  completed,  implementation  and 
simulation  of  the  actual  software  model  begins.  Finally,  the  entire  system  with  all  of  the  actual 
application  software  is  being  simulated.  This  method  ot  system  development  provides  flexibility 
with  a minimum  investment  in  aetual  hardware  ami  maximum  possibility  of  ultimate  system 
success. 


C.  SIMULATION  APPROACH 

1.  Defintinn  of  Terms 

In  order  to  remove  any  ambiguity  concerning  simulation  terminology,  the  following  terms 
will  be  utilized  in  describing  the  DP'M  Simulation  System.  A system  is  a collection  of 
lunctionally  and  logically  related  entities,  each  characterized  by  attributes  which,  in  turn,  may  be 
related  among  themselves.  An  entity  denotes  an  object  of  interest  in  a system.  An  attribute 
denotes  a property  of  an  entity  An  event  signifies  a change  in  a stale  of  an  entity.  For  example, 
an  aircraft  and  its  pilot  can  be  considered  to  constitute  a system:  the  entity  “aircraft”  has  the 
: t tributes  of  type,  cost,  etc.;  t he  entity  “pilot”  may  he  described  in  terms  of  his  aye, 
qualification,  etc.  Relationships  between  entities  may  he  classified  into  static  relationships  and 
dynamic  relationships.  Furthermore,  dynamic  relationships  can  be  expressed  as  deterministic 
linn  lions  of  time  or  as  stochasth  linn  limn  ot  time,  or  as  a mixture  of  both. 

2.  Simulation  Control  Structure 

The  UP/M  Functional  Simulation  System  is  a discrete  event-oriented  simulation  system 
built  around  a nucleus  of  common  model  independent  utility  routines.  Unlike  a continuous 
system  where  transitions  from  one  state  to  the  next  are  a continuous  function  of  time,  within  a 
discrete  system,  transitions  from  one  stale  to  another  occur  at  discrete  time  points.  In  discrete 
systems,  distinguishable  state  Initiations  are  called  events.  Thus,  an  event  can  occur  only  at 
specific  times,  and  there  are  no  changes  between  events:  furthermore,  an  event  is  an  idealized 
phenomenon  of  zero  duration.  Fvcnt  oriented  simulation  systems  emphasize  a detailed 
description  of  the  steps  that  occur  when  an  individual  event  takes  place. 

Simulation  control  structures  within  a discrete  event-oriented  simulator  are  represented  by 
Figure  I C2.  The  Simulation  Control  Algorithm  CSC  A)  controls  simulation  time,  maintains  the 
Future  Fvcnt  Fist,  and  provides  any  ancilliary  system  routines.  The  heart  of  the  simulator  is  the 
Future  Fvcnt  List.  The  Future  liven  I List  (FFI.l  is  a chronologically  ordered  list  that  contains 
event  notices.  Associated  with  each  event  notice  is  an  activity  routine  that  simulates  the  actions 
ot  the  particular  event  to  be  modeled.  The  SCA  removes  the  first  notice  from  the  FFL.  advances 
simulation  time  to  the  time  associated  with  the  event,  determines  which  activity  routine  is 
associated  with  that  event  and  passes  control  to  it.  Simulation  time  may  be  advanced  to  the  time 
associated  with  the  next  FFL  entry  since  the  FFL  is  chronologically  ordered,  thus  there  can  be 
n<>  event  before  the  first  element  on  the  FFL.  Thus,  time  is  determined  by  the  sequence  of 
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Figure  102-  Simulation  Control  Structure 


events  and  not  by  some  fixed  interval.  This  characteristic  is  sometimes  referred  to  as  a variable 
time  increment  or  next  event  approach. 

Each  activity  routine  performs  essentially  the  same  task.  First,  it  destroys  its  event  nt-ilce. 
after  extracting  any  pertinent  information,  by  returning  it  to  dynamic  memory.  Next,  the 
activity  must  test,  via  its  data  structures,  if  all  precedence  relationships  have  been  satisfied..  If 
not.  the  activity  is  placed  on  a waiting  queue  until  such  time  that  the  constraints  are  satisfied.  If 
all  constraints  are  satisfied,  the  activity  ma>  be  executed,  thus  changing  the  state  of  the  system. 
Necessary  statistics  are  then  gathered.  Finally,  a new  event  notice  is  generated,  a time  for  the 
event  to  be  executed  in  the  future  is  computed,  and  the  event  notice  is  returned  to  the  SC'A  to 
be  placed  on  the  FEL.  The  SCA  will  then  remove  the  next  event  from  the  FEL  and  proceed  in 
the  same  manner  as  heft  *e. 

3.  Basic  Simulator 

In  order  to  efficiently  implement  the  simulation  approach  previously  described,  certain 
useful  characteristics  were  identified  and  package  of  routines  that  provides  a powerful  tool  for 
the  development  of  discrete  event-oriented  simulation  systems  was  developed.  This  Basic- 
Simulator  is  characterized  by  model  independence.  FORTRAN  orientation,  dynamic  memory 
management,  list  processing  facilities,  clock  management,  random  number  generators  and  error 
diagnosis  and  reporting. 
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ilie  functions  performed  within  the  simulation  approach  are  completely 
the  actual  system  to  he  simulated.  In  order  to  make  the  Basic  Simulator 
wide  r.m.ee  of  potential  simulation  problems,  as  much  of  the  package  as  possible 
to  provide  the  tools  to  develop  a discrete  event-oriented  simulation  system 
knowledge  of  Hie  system  to  be  simulated. 


h.  I’ORTR.W  Dri  fill  a lion 


Tlie  Basie  Simulator  approach  offers  several  important  features:  (l)tlie  user  need  not  learn 
a new  i specialized » programming  liinyiia^c.  i.e..  it  uses  FORTRAN  as  a base  language;  (2)  all 
standard  facilities  of  the  host  operating  system,  on  which  the  Basic  Simulator  is  installed,  are 
icai'ily  .callable  to  the  user  in  a familiar  way;  (3)  it  is  possible  to  develop  a simulation  system 
that  nia)  he  transported  to  other  computer  systems  that  have  compatible  FORTRAN  compilers 
and  operating  system  capabilities. 

v.  Dynamic  Memory  Mnnafnoneni 

Dynamic  memory  management  of  storage  required  by  the  simulator  provides  the  capability 
to  manipulate  during  program  execution  a vector  of  common  memory  so  that  blocks  from  that 
vector  can  be  tempoi  irily  allocated  to  the  user’s  program  and  then  deallocated  when  no  longer 
needed.  This  memory  management  method  makes  it  possible  to  reuse  the  same  storage  many 
times  for  different  purposes  throughout  a simulation  run  and.  thus,  not  only  minimize  total 
program  storage  requirements,  but  also  increase  the  size  of  the  simulation  problem  that  can  be 
handled. 

At  any  instant  the  memory  vector  consists  of  two  types  of  blocks;  (I ) those  that  are 
allocated  and  currently  in  use;  <2)  those  that  are  deallocated  and.  thus,  are  available  for  use.  All 
deallocated  blocks  are  chained  together  as  a linked  list,  which  is  called  the  Free  List.  When  a 
program  requests  a block  of  memory  the  Free  List  is  searched  to  find  a deallocated  block  of 
sufficient  size.  The  sei'-ch, ’allocation  strategy  works  as  follows:  (I ) during  the  search,  physically 
adjacent  blocks  in  the  Free  List  are  collapsed  into  a single  large  block;  (2)  the  requested  block  is 
allocated  from  the  first  sufficiently  large  free  block  encountered  in  this  search.  If  no  such  block 
c.m  be  found,  further  execution  of  the  simulation  program  is  terminated. 

it 

The  Dynamic  Memory  consists  of  the  following  major  routines: 

Ml  MAI  X Allocate  Memory  This  routine  is  used  to  allocate  a block  of  memory 
from  the  Free  List. 

Ml  MI  RX  Deallocate  < Free  I Memory  This  routine  is  used  to  free  an  allocated 
block  of  memory  and  to  return  it  to  the  Free  List. 

, Mh.MZOX  Stoic  Zeroes  in  Memory  This  routine  is  used  to  store  zeroes  in  all  user 

available  words  of  a specified  memory  block. 

d List  I’roressinu  !• acHiiies 

In  order  to  allow  efficient  representation  ol  the  data  structures  within  the  simulator,  as 
Well  a>  to  provide  floible  method.,  of  modification  to  those  data  structures,  some  type  of  list 


| processing  tacihty  is  required  In  addition,  list  strut. tores,  in  paiticuiai  queues  jUmw  tm  g.itiicii  ig 

ol  uselu’  statistics  concerning  system  variables.  Poi  example,  to  measure  the  loading  ot  a 

j coiniuun.tation  hus.  data  are  placed  on  a hus  queue  tor  the  length  ol  time  that  would  !>e 

J required  to  deliver  that  data  to  some  receiver,  and  removed  h,  the  receiver  so'iietime  latei 

Queue  statistics  are  automatically  gathered  that  provide  such  u.. urination  as  minimum  maximum 
si/e.  mean  time  on  queue,  standard  deviations,  etc.  Thus,  list  structures  provide  ellieienl  means 
ol  measuring  system  parameters 

List  processing  facilities  developed  for  the  Basic  Simulator  are  used  for  defining,  searching, 
adding  deleting  elements  and  maintaining  standard  list  statistics  lor  doubly -linked  lists. 

The  List  Processing  Facilities  consist  ot  the  following  major  routines. 

LTDFFX  Define  a List 

I This  routine  creates  a standard  list  head  and  then  stores  into  it  information 

[ which  defines  and  initializes  the  new  list 

LI  ADDX  Add  an  (-.lenient  to  a list 

Tins  routine  adds  a new  element  to  the  correct  logical  position  in  the  list 
identilicd  In  the  list-head  pointer. 

LTF’NDX  Find  a Specific  ( lenient  in  a List 

This  routine  searches  a list  in  the  direction  ol  decreasing  rank  ol  its  elements 
to  find  an  element  which  contains  a specific  value  stored  in  a specified 
word. 

■ (TNXTX  Return  a Pointer  to  the  Next  Ficinent  in  a List 

(nven  a pointer  to  an  element  in  a list,  this  routine  returns  the  pointer  to  the 
element  which  is  logically  next  to  the  first  pointer. 

1.1  RSPX  Remove  a Specific  Fitment  from  a List 

Tins  routine  removes  a specific  element  Irorti  the  specified  list 

e Cluck  Management 

The  (lock  Management  portion  of  the  Basic  Simulator  makes  11  possible  to  simulate 
concurrent  processes  by  representing  each  process  as  a sequence  ol  events.  The  flow  of  control 
during  simulation  is  managed  by  means  ot  a time-ordered  list,  called  the  Future  ( vent  last 
(IT  Ll.  which  contains  the  event  notices  lor  events  scheduled  to  occur  at  some  future  tune  The 
(lock  Management  consists  ol  the  follow  mg  major  routines. 

S(  111)1  X Schedule  an  I vent 

This  routine  places  an  event  notice  on  the  Future  (-.vent  List 

( NJRYX  ( alculate  the  Fntry  Address  to  a Subprogram 

This  function,  coded  in  assembly  language,  is  used  to  compute  the  run-time 
entry  point  address  ot  a FORTRAN  subroutine 

( ANC1  X Cancel  a Future  ( vent  Notice 

(Ills  routine  cancels  a future  event  notice 

f Randum  Sumber  Generators 

Many  phenomena  within  the  DP  M system  aie  stochastic  -ri  nature.  In  order  to  be  able  to 
accurately  model  these  random  processes,  random-number  generation  capability  was  provided 


Hi.'  i.unioni-numbci  generators  developed  pioviJr  l.nili'ies  lor  producing  sequences  ol  random 
numbers  t r. >m  simulant  Nt.iiistK.il  distiihutions  most  commonly  used  in  sinml.ition.  as  well  as  Inr 
gen. ratlin*  r.nnlom  numbers  trom  continuous  ml  discrete  distributions  dflmed  In  the  user 

V / rmr  Puiitnnus  ami  Re/tnriim; 

III.-  ami  diagnosis  ami  reporting  capabilities  developed  provide  tile  user  with  tooh  In; 
Jei’ucei  .•  simulation  programs  In  particul.il.  three  hasn  tvpesot  tools  are  provided  1 1 1 those 
lor  writing  diagnostic  messages  ami  toi  optionally  hall  mil1  further  simulation  execution  t2i those 
loi  the  validity  ol  oper.ition.il  p iranieters  ami  suhroiiline  arguments  relative  to  Dynamic 

Meniorv  ru!  list  processing  opeiat ions  i '•  those  tor  dumping  le  e prn.t mu » the  contents  ol  the 
data  aggregate-'  01  structures  typicullv  use. I in  simulation,  sin  I.  as  varum*  portions  ol  | >\  u.iiiik 
Memory.  I.sts  or  vectors  I hose  checks  perlormed  in  nuinhei  two  are  user  controllable.  and  max 
he  suppressed  it  not  returned  to  imrease  simulation  elticie.cv 

D.  SYSTEM  NETWORK  SIMULATOR 

1.  System  Network  Simulator  Models 

I he  DP  M System  Network  ‘simulator  is  basically  a trallie  simulator  used  to  study  the' 
topological  vonsider.it tons  ol  the  DP  M network  As  sitvh.  it  is  a high-level  simulator  I he 
corresponding  models  that  torm  the  simulator  are  eomerned  with  forming  a structure  with 
emphasis  on  variability  ol  those  design  pa.ameters  at  the  DP  \1  network  level  In  particular,  the 
System  Network  Simulator  was  used  to  atialy/e  and  evaluate  t 1 1 processing  element 
v haras terist ics  vapahihties.  (2t  number  ol  resources  in  the  svstem.  < ’I  local  and  global  bus 
cont ieiir.it ion.  <4)  mter-PI  communisation  teclmu|ue.  tsiPl  Bus  protocol  vomnumnation 
tevhnii|ue.  li>l  executive  control  techni«|iie  lo  I tilt  ill  the  goals  ol  the  DP  M Svstem  Network 
Simulator  the  tollowmg  models  were  developed  < I i Bus  ( ontrol  Model  (2i  Avionic  f unction 
Program  Models.  I v|  I \ccutive  Models 

Ihe  avionic  function  program  models  describe  the  execution  ot  an  avionic  program  tor 
cadi  PI  m terms  of  the  time  to  execute  the  modeled  avionic  program,  meniorv  wools  r.qutred. 
..ml  messages  generated  lot  the  local  and  global  buses  by  that  program  Avionic  program 
execution  times  tor  a PI  are  determined  trom  the  execution  time  estimates  lor  mdiv.dua1  tasks 
generated  by  the  svstem  requirements  el  tort  Ihe  execution  tunes  are  described  in  units  ol  basic 
processor  operations  per  second  Ihe  message  tr.dlic  generated  I >r  the  svstem  communication 
buses  is  derived  bv  the  svstem  require nients  e'tort 

Ihe  executive  model  simulates  in  dcta'I  the  scheduling  algotithm  ol  the  executive  The 
executive  scheduling  algorithm  determines  which  ol  Mie  tasks  are  lo  be  executing  it  anv  one 
instant  in  time  Ihe  bus  control  model  simulates  the  message  sequencing  piotovol  activities  ol 
the  Local  and  (ilohul  buses  Ihe  perlorni.uic e ot  the  buses  is  modeled  in  terms  ol  the  bus 
allocation  algorithm  lacli  ol  these  models  are  discussed  in  detail  in  subsequent  paiagiaphs 

2.  Svstem  Network  Simulator  List  Structures 

In  order  lor  the  System  Network  Simulutoi  lo  be  ellicient  and  elle.  live  it  must  allow 
variable  DP  M conligur.it ions  to  be  evaluated  without  a ni.uor  inodilivution  lo  Ihe  simulator 
itselt  lor  example,  one  series  ol  evaluation  might  be'  concerned  with  studv  me  the  el  led  ol 
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liiiiim.il  includes  such  (liiii|>s  as  processors,  sensors.  Inis  controllers,  interrupt  generators,  etc. 
I.ich  tcnninal  device  lias  a list  structure  as  defined  in  Figure  103.  The  first  seven  words 
coiiv -spnml  to  the  format  of  a standard  event  notice.  PRIDZ  contains  the  processor  identity 
number.  ARGTZ  contains  a pointer  to  a list  of  parameters  that  are  unUpicly  associated  with  the 
current  event  routine.  MSGK)  contains  a pointer  to  a queue  that  contains  any  input  messages 
required  hy  that  terminal.  MSGOQ  contains  a pointer  to  the  queue  that  contains  any  output 
messages  required  hy  that  terminal.  BIJSYQ  contains  a pointer  to  a queue  that  contains  any 
output  messages  from  the  terminal  that  are  currently  on  the  Inis.  INTRO  contains  a pointer  to  a 
queue  that  contains  any  events  that  have  been  interrupted  and  have  not  completed.  PRTYZ 
contains  the  priority  of  the  current  event  routine.  POL1.Z  contains  the  polling  period  if  the 
terminal  device  lias  a polling  loop.  FARM/,  is  the  first  word  of  a list  of  parameters  that  are 
uniquely  associated  with  the  terminal  device. 

4 PL  Inlerconne  livity 

Ihe  1*1  ■ mterconncctivity  list  structure  in  figure  lt)4  provides  the  mechanism  to  describe 
mil  vary  the  physical  connectivity  of  the  Local  and  Global  buses  without  modification  to  the 
simulator.  For  each  affinity  group,  a Local  Inis  connectivity  list  as  well  as  an  entry  in  the 
|’L-al finil\  group  association  list  is  generated.  Likewise,  a global  bus  connectivity  list  is  generated 
describing  the  global  IT  inierconncclivity.  Current  Position  of  Control  (CPC)  pointers  are 
initialized  to  the  first  PL  within  each  list.  A.  the  completion  of  each  message  transmission  over  a 
b„s.  the  CPC  pointer  is  advanced.  All  messages  are  checked  to  verify  that  the  destination  PF.  is 
actually  connected  to  the  transmitting  PF.  The  PL-AI’finily  Group  association  list  is  utilized  to 
locale  I lie  correct  Affinity  Group  for  a transmitting  PL. 
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figure  104.  PI-  liilcrcoiiiicclivfly  Llsl  Structure 
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I ogieal  Precedence  Relationships  between  tasks 

In  ordei  lo  provide  flexibility  within  the  Sys*em  Network  Simulator  so  that  various 
1’!^ steal  organizations  may  he  evaluate*!,  a nccessaiy  ret|uireineul  is  that  logical  precedence 
lelalioiisliips  between  tasks  he  represen  table  iinlepeinlenlly  of  physical  considerations.  I his 
sepat.il ion  ol  topical  ami  physical  relationships  can  he  accomplished  hy  use  of  the  following 
procetlure:  ( 1 1 describe  system  topical  prece«lenee  relationships  as  directed  graphs.  f 2)  describe 
i.oks  m terms  of  pertinent  parameters.  t.D  represent  messape  (data!  transmittal  lo  processors  hy 
input  and  output  queues.  (It  pass  all  output  messape  reipiests  to  a virtual  messape  distributor 
ilia!  is  eopni/anl  of  the  actual  method  in  which  data  is  lo  he  transmitted. 

(».  DI’M  lest  Mission  Characteristics 

l 'snip  the  previously  discussed  puidelines.  a hyp**lhelical  test  mission  was  formed  which 
closely  resembled  an  air-'o-proond  ( hue  Air  Support  tCASl  quick-reaction  mission  apainsl 
sliorl-lile  targets  such  as  tanks  or  trucks.  The  set  of  functions  was  selected  to  allow  some  of  the 
more  demandiup  dipilal  processing  loads  for  DIVM  testing  and  analysis,  and  are  not  intended  lo 
teptesenl  any  one  given  or  complete  avionic  configuration  for  a particular  mission,  l or  example, 
the  inclusion  of  an  inertial  slrapdown  navigation  system  in  a (’AS  avionics  suite  is  unlikely; 
however,  an  inertial  slrapdown  system  was  included  because  it  poses  a more  demandiup 
'computational  load  on  DIVM  than  does  an  ordinary  pinihaled  inertial  navigation  system. 

light  classes  ol  mission  functions  were  debited  for  DI'  VI  analysis  These  eight  mission 
liincbous  include. 

i I t Navigation 
(2)  banding 
t.D  Air  Data 
i-ll  blight  Control 
( 5 1 I iie  ( ’ontrol 
(ill  Vehicle  Defense 
(7)  Stores  Management 
(X)  System  Management. 

Associated  with  each  of  these  general  functions  are  definite  modes  of  operation  cahed 
siihlimctions.  l or  example,  within  the  navigation  function  there  are  the  sublime! ions  of  I oran. 
Inertial  Slrapdown.  as  well  as  various  alternate  and  backup  modes  of  navigation  operation.  Ibis 
classification  of  functions  and  suhfunclions  closely  resembles  the  way  in  which  the  pilot  or 
mission  manager  views  his  avionic  system.  A third  level  ,*f  definition  is  required  for  the  system 
architecture  and  digital  processor  designer  and  this  is  the  task  level  of  definition.  A task  is  a 
logical  unit  of  the  suhfunction.  and  is  usually  associated  with  a well  defined  activity  or  process 
within  the  suhfunction.  such  as  the  receiver  interlace  task  within  l.oran.  bor  the  most  part, 
discussion  concerning  DIVM  mission  processing  will  center  on  siihlimctions  and  their  associated 
tasks.  A summary  of  the  DIVM  mission  functions,  siihlimctions.  and  tasks  that  were  defined  is 
given  in  Table  24. 
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TABLE  14.  IJP'M  SYSTEM  PROCESSING  TALKS 
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TABLE  24.  DP/M  SYSTEM  PROCESSING  TASKS  (Continued) 
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Figure  105.  W/M  Test  Mission  Time  Line 


For  the  purpose  of  testing.  a hypothetical  test  mission  time-line  analysis  was  formed 
showing  the  aetive  mission  segments  tor  each  suhtunetion  in  the  system  Tins  time-line  had  the 


following  1 1 

; mission  segments: 

ill 

Prellight 

<2l 

Takeoff 

(31 

Climb 

(4) 

Cruise 

(51 

Arm  Weapons  Activate  l-CM 

(61 

Attack  and  Weapon  Delivery 

( 7 1 

Evade  and  Depart 

18) 

Cruise 

(9) 

Descend 

< JOl 

Land 

(III 

Post  flight. 

The  pilot  serves  as  the  system  manager  during  the  mission,  and  as  such  is  responsible  tor 
initiating  either  master  modes  of  operation  (e.g..  select  one  button  and  cause  activation  ot 
multiple  subfunctionsi  or  activation  ot  individual  subt unctions  The  time-line  analysis  showing 
active  mission  subfunction  per  mission  segment  is  shown  in  Figure  105. 

7.  Data  Analysis  and  Recording  Example 

To  illustrate  the  process  ol  gathering  and  recording  suhl unction  data  for  use  either  as 
input  to  the  SNS  or  process  construction  analysis,  the  Loran  avionic  algorithm  will  be  discussed 
Initially,  the  Loran  algorithm  was  analyzed  and  divided  into  live  basic  tasks.  Each  task  is  then 
described  in  terms  ol  'is  scheduling  requirements,  inputs,  computational  requirements,  and 
outputs  This  type  ot  information  is  represented  in  Table  25.  The  next  step  is  to  establish  the 
interrelationship  ot  the  tasks  to  one  another  in  the  form  o!  a directed  graph.  The  directed  graph 
shows  necessary  predecessor  conditions  that  must  occur  prior  to  task  initiation,  as  well  as 
information  (message!  How  between  tasks  The  general  convention  lor  directe  ' fraph  representa- 
tions of  a task  is  illustrated  in  I igure  1 06  The  directed  graph  representation  ol  the  given  Loran 
(unction  is  shown  in  Figure  10” 

Once  the  information  concerning  a suhtunetion  and  its  tasks  is  recorded,  tlu  data  can  be 
prepared  for  input  to  the  simulator  The  simulator  builds  a list  structure  describing  the  directed 
graph  and  a data  base  for  each  task  A portion  ot  the  actual  input  data  for  the  Loran 
sahlunction  i*  shown  in  Tabic  2o 

Figure  I Oh  describes  flic  list  structure  used  to  represent  cadi  task  One  ot  these  list 
structures  is  generated  tor  each  task 

In  order  to  represent  the  receipt  and  transmittal  ol  dalj  a processor  has  an  input  queue 
repicsenting  data  received  and  an  output  queue  representing  data  to  be  transmitted  over  the  bus 
network 
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TABLE  25.  LORAN  FUNCTION  PROCESSING  TASKS 
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Figure  106.  Directed  Graph  Representation  Convention 
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Figure  10*  Lorjn  Directed  Graph 


K.  Virtual  Message  Distributor 

lla.ing  described  til'.'  Ikl’k.iI  pi c«. ciit-nv c relationship-  between  tasks  .uni  their  pertinent 
parameters.  one  additional  set  oi  mlorm.ilion  is  necessarv  to  simulate’  the  performance  ot  the 
|)|*  M system  In  particular  the  actual  assignment  ot  tasks  to  P|  s t Process  ( (instruction)  and  the 
1*1  mte.'connectivity  are  necessary  to  complete  the  s\nU  , spec ilicalion  lask  assignment  is 
specitied  l>>  a simple  list  ot  task  identiluatiou  nuinher  tor  each  PI  Ml  ol  the  physical 
characteristics  ol  the  system  are  utilized  In  the  Virtual  Message  Distrihutor  iVMDl  to  actually 
simulate  the  data  llovc  within  the  l)P  M system  Notice  that  the  logical  precedence  relationships 
are  independent  ol  the  actual  method  ol  inter  task  data  transmittal  Only  the  VMI)  is  cognizant 
ol  the  method  ol  data  transmittal  which  is  a (unction  ol  the  physical  characteristics  ot  the 
system  All  data  delivery  requests  pass  through  the  VMI)  which  does  the  actual  data 


TABLE  26  LORAN  SNS  INPUT  DATA  EXAMPLE* 
LOR  AN  POSITION  FIX 
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input  format  corresponds  to  a FORTRAN  NAMH.IST  function. 
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transmission.  As  described  previously,  data  is  either  on  an  input  queue  waiting  to  be  used  or  on 
an  output  queue  waiting  to  be  transferred  by  the  bus  network.  The  VMI)  has  the  destination 
tasks  for  a data  set  via  the  logical  precedence  information  as  well  as  physical  assignments.  Thus, 
the  VMD  can  determine  if  the  data  set  must  be  transported  over  the  bus  network  in  the  case 
where  the  destination  task  is  not  collocated  with  the  source,  or  may  be  placed  directly  into  the 
input  queue  in  the  case  where  the  destination  task  is  collocated  with  the  source.  An  illustrative 
analogs  is  the  case  of  mail  delivery.  A person  I task)  addresses  an  envelope  I message  request) 
containing  a letter  (data)  to  be  delivered  to  a person  (another  task).  The  envelope  is  then  picked 
up  by  the  mailman  (VMD)  who  determines  how  and  where  the  letter  should  be  delivered. 

9.  Model-Dependent  Routines 

The  model-dependent  routines  are  built  using  Basic  Simulator  routines  to  actually 
construct  a simulator.  To  be  precisely  correct,  model-dependent  routines  are  all  those  routines 
that  are  not  explicitly  part  of  the  Basic  Simulator,  however,  there  is  a class  of  model-dependent 
routines  that  are  general  in  nature.  These  routines  are  designed  for  a specific  data  structure 
organization  and  a specific  generic  class  of  simulation,  namely  distributed  computer  network 
simulation.  However,  these  routines  are  not  predicated  on  a particular  model  of  one  of  the 
system  components,  i.e..  bus.  processors,  executive,  etc.  These  general  routines  allow  investiga- 
tion of  a large  class  of  system  configurations  with  different  components  without  a complete 
System  Network  Simulator  redesign. 

The  following  subsections  denote  these  general  routines  developed,  along  with  a brief 
description  of  their  function  and  a comment  on  their  use.  Note  that  for  a majority  of  the 
routines,  a particular  data  structure  is  assumed:  however,  the  data  structure  elements  are 
referenced  by  name  and  the  actual  position  within  the  structure  is  not  important  to  the 
operation  of  the  routine.  These  routines  provide  a general  system  specification  mechanism  as  well 
as  additional  tools  for  simulator  development. 

a.  ASSIGN  (Task  Assignment ) 

The  task  assignment  routine  makes  entries  into  the  task  definition  list  structure  to  assign 
avionic  tasks  to  a particular  processing  element  as  defined  by  user-specified  data.  Figure  109  is  an 
example  of  the  report  generated  by  the  ASSIGN  routine.  This  routine  is  used  to  define  the 
avionic  task  configuration  independently  of  a particular  physical  configuration. 

b.  DEFGEX  (Define  GEX  Time-Ordered  List  t 

This  routine  builds  the  time-ordered  list  required  by  the  Global  Fxecutive  (GFX) 
scheduler 

c.  INTEND  (Interrupt  End i 

The  interrupt  end  processing  routine  is  used  by  an  end-of-interrupt-processmg  event  to 
restart  the  interrupted  event. 

d.  INTSET  (Interrupt  Set) 

The  interrupt  process  routine  interrupts  a currently  running  process  it  the  priority  of  the 
interrupt  is  higher  than  that  ot  the  currently  running  process  and  places  the  interrupted  process 
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Figure  109.  Physic*!  Assignment  Report 


on  a waiting  queue.  It'  the  priority  of  the  interrupt  is  lower  than  that  of  the  currently  running 
process,  the  interrupt  is  placed  on  a waiting  queue  The  entries  in  the  waiting  queue  arc  removed 
by  the  INTtN’D  routine.  INTSl  T,  in  conjunction  with  INTI  Nl).  allows  tor  ease  ol  simulation  ot 
multi-level  interrupt  structures 

e.  READCM  (Read  Connectivity  Matrix) 

The  read  connectivity  routine  reads  the  user-specified  Local  and  (ilohal  hus  connectivity 
definitions  and  huilds  the  corresponding  processing  .lenient  connectivity  data  structures.  This 
routine  allows  for  flexibih'v  in  the  definition  of  the  DP  M busing  structure. 

/.  TESTCM  ( Test  Connectivity  Matrix) 

The  test  connectivity  matrix  routine  is  called  by  the  ASSIGN  routine  to  test  for 
consistency  between  PI  connectivity  definition  and  task  assignments.  In  addition,  this  routine 
determines  whether  the  distribution  of  a message  should  be  over  the  Local  or  Global  bus  and 
sets  an  indication  in  the  message  data  structure. 

jf.  TSKDEF (Task  Definition) 

The  task  definition  routine  reads  the  user-specified  task  definition  data  and  then  builds  the 
associated  list  structure.  Table  l1  describes  the  input  format  for  the  task  definition  data  The 
task  definition  data  is  used  to  describe  the  logical  precedence  relationships  between  tasks  and 
their  pertinent  parameters 

h.  WAKE  CP 


The  wakeup  routine  will,  it  the  event  time  for  a particular  event  is  infinity  ti  e.,  put 
asleep),  schedule  the  event  passed  to  it  at  a time  equal  to  urrent  simulation  time  plus  a 
normally  distributed  random  n.Vger  number  in  the  interval  (O.X).  X is  the  event  sample  rate  as 
specified  in  its  definition.  If  the  event  time  is  not  infinity,  the  v akeup  routine  performs  no 
action.  The  wakeup  routine  provides  the  capability  to  place  events  i an  idle  state  when  further 
simulation  is  not  required  and  to  be  "awakened"  when  simulation  is  required. 

i.  XFER 

The  bus  transfer  time  routine  calculates  the  time  required  to  transmit  a particular  message 
over  the  bus  The  transfer  turn  . . a function  ot  message  length  in  words,  number  of  bits  in  the 
message  sync,  the  bit  period,  and  the  gap  tune 

finally,  under  the  class  of  inodd  dependent  routines  are  those  routines  that  explicitly 
model  the  performance  ol  each  ol  the  particular  entities  in  the  system.  These  routines 
correspond  to  the  starting  and  ending  events  lor  each  entity.  In  fact,  these  routines  are  the  DP  M 
System  Network  Simulator.  These  routines  have  been  designed  with  as  much  flexibility  as 
practically  possible  to  provide  the  capability  to  investigate  various  alterations  in  the  model  The 
following  is  a list  of  the  model-dependent  routines  along  with  a brief  discussion  of  their 
function. 
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10.  Bus  Control  Model  L vents 


a (IBl'SCR  i (i 'lohal  Bit s Control  Receive) 

I he  Global  Inis  control  receive  event  routine  removes  a message  I rout  the  (ilobal  bus 
queue  and  places  it  on  the  destination  processing  element!  si  input  i|  lie  net  si 

b (IBt  SCW  I Global  Bus  Control  Transmit) 

I he  Globa!  bus  control  transmit  event  lotilmc  attempts  to  remove  a message  trout  the 
output  queue  ot  the  processor  that  currently  has  the  bus  control  It  a message  is  present. 
tiBISl  \ places  it  on  the  Cilobal  inis  queue  and  schedules  the  (ilobal  bus  control  receive  event  at 
a later  time  equal  to  the  transmission  time  ot  the  message  It  no  message  is  present  on  the 
processor  output  queue,  a sv  ik  signal  is  generated  and  the  routine  is  rescheduled  at  a later  time 
equal  to  a bus  control  pass  time  In  either  case,  bus  control  position  is  advanced  to  the  next 
processing  element  in  the  loop  The  model  developed  also  allows  lor  supercommutation  ot  one 
or  more  processors  lie.  a processor  may  gam  access  to  the  bus  at  a higher  ! requeues  than  other 
processors  i 

Io  increase  simulator  elticieiicv  with  in*  loss  m information  or  simulation  accuracy,  the 
(ilobal  hus  control  transmit  event  places  itseil  into  an  idle  state  it  no  messages  are  delivered 
during  a complete  pass  around  the  bus  \nv  event  that  generates  ..n  output  message  will 
"wakeup  " the  bus  control  event  \t  that  point,  the  actual  simulation  ot  the  bus  pertormance.  in 
terms  ot  transferring  messages,  pissing  o|  control,  etc  . continues  as  it  the  event  had  never  been 
idle 


«■  LBCSCR  I Local  Bus  Control  Receive). 

LB  l SC.\  I Local  Bus  Control  Transmit) 

Jhe  I ocal  bus  control  receive  • transmit » event  routine  lunciions  exactly  as  does  the  Global 
bus  control  receive  itr.msimti  ev.  nt  ex.ept  that  it  models  the  local  buses  in  the  system 

1 1 \v  ionic  Task  Model  t vents 

I uch  avionic  task  is  modeled  b>  two  events,  the  task  start  event  and  the  task  end  event 
1 liis  is  necessary  to  be  able  to  simulate  the  total  execution  time  lor  the  task  The  1 oca! 
I xeciitive  <11  \l  model  transfer*,  control  to  the  task  start  event  when  the  conditions  ate  proper 
I he  task  star!  event  schedules  the  end  event  at  a tune  equal  to  now  p.  i*  the  execution  time  ot 
the  task  Ibis  simulate'  total  task  time  The  end  event  saves  the  task  II).  status,  and  branch 
successor  ulentil ication  il  any  and  schedules  the  output  message  request  module,  thus  leturmng 
control  to  the  1 1 \ 

I 2.  Lxccutive  Model  Events 

Ihe  executive  mode!  events  >\actly  tollow  the  logical  decisions  made  b’  e Local  and 
Global  I xvciitiivs  I rum  the  simulation  standpoint  the  executive  events  are  no  di  lerent  Iron* 
anv  other  event  within  the  system 


a. 


ISTTIM  (interval  Timer) 


The  '...lerval  timer  event  simulates  a GkX  programmable  interval  timer  interrupt  and  .alls 
the  (it  X tune  scheduler. 

b GkXTi.M  (GEX  Time  Scheduler) 

The  C.l  X time  scheduler  event  schedules  all  subfunctions  in  the  system.  It  uses  and 
maintains  a time-ordered  list  ot  subfunction  start  times.  It  also  monitors  the  active,  abort,  and 
complete  flags  associated  with  subfunctions. 

c GEXEXD  ( GEX  Time  Scheduler  End) 

Ihe  (.'»!•  X time  scheduler  end  event  schedules  the  programmable  interval  timer  event  based 
upon  (il  XTIM  computations 

d iMSG  (input  Message  Scanner ) 

The  input  message  scanner  foi  the  LtX  event  routine  processes  messages  transmitted  over 
the  Local  or  Global  buses.  It  provides  association  between  messages  and  recipients  and  requests 
data  moves  to  the  dispatcher  if  necessary.  It  also  incorporates  a model  for  receiving  activate/ 
deactivate  and  completion  command  messages  from  subfunctions. 

e DEC  MS  T (Decrement  Predecessor  Count) 

This  routine  is  a LKX  event  that  decrements  predecessor  counts  of  subfunctions. 

f.  O.MSG  (Output  .Message  interpreter ) 

The  output  message  interpreter  is  a LKX  event  that  processes  output  message  requests  and 
places  them  on  the  processor  output  queue. 

g SCi/ED  (LEX  Task  Complete) 

This  event  routine  performs  the  task-complete  processing  for  the  LKX. 

h BSSCAS  (Branch  Successor  Scan) 

I his  event  routine  scans  the  branch  successor  list  and  decrements  the  predecessor  count  if 
the  task  supplies  a branch  successor  ID. 

i DiSPI\  (Dispatcher) 

This  routine  is  a service  module  called  by  several  submodules  to  reset  flags  and  move  ready 
tasks  to  the  ready  queue. 

j SSCA  \ (Successor  Scan) 

This  event  routine  examines  the  preamble  of  the  completing  task's  successors  and 
decrements  predecessor  counts 


A.  IMSCAN  Unpin  Message  Scan) 


The  input  message  scanner  for  the  GKX  event  routine  processes  messages  transmitted  over 
the  Local  or  Global  buses  It  provides  association  between  messages  and  recipients  and  requests 
moves  to  the  dispatcher  if  necessary. 

/.  OMRQST  (Output  Message  Request ) 

The  output  message  request  interpreter  is  .1  GhX  event  routine  that  processes  message 
requests  front  tasks  and  prepares  them  for  output  by  placing  them  on  an  output  queue. 

13.  Data  Collection  and  Report  Generation 

A family  of  data-collection  and  report-generation  programs  was  developed  for  the  System 
Network  Simulator.  These  programs  provide  the  capability  to  selectively  collect  data  on  and 
generate  reports  for  the  various  system  parameters  under  investigation  for  a particular  DPM 
configuration  and/or  avionic  mission  segment.  Both  the  collection  and  dispensation  of  data  as 
well  as  the  generation  of  reports  are  controlled  by  user  specified  parameters.  In  general,  the  user 
has  four  options:  (lino  data  is  collected  and  no  reports  generated:  (2)  data  is  collected  and 
saved,  but  no  report  generated:  (3)  data  is  collected  and  report  generated  but  data  not  saved: 
(4)  data  is  collected  and  saved,  and  reports  generated.  Data  saved  on  magnetic  tape  may  be 
processed  at  a later  time.  In  fact,  this  saved  data  may  be  used  at  a later  time  to  compare  results 
ot  two  or  more  different  simulation  experiments.  However,  care  must  be  exercised  when 
comparing  results  generated  using  random  numbers.  The  particular  options  available  are  discussed 
in  detail  in  the  following  subsections. 

Data  collection  and  report  generation  occur  at  three  distinct  levels:  ( I ) event  level. 
(2)  sample  period  level.  (3 • postsimulation  level.  At  each  of  these  levels,  reports  concerning  bus 
performance,  processor  loading,  executive  performance,  and  number  ol  avionic  tasks  processed 
may  be  selectively  generated. 

a.  Event-Level  Reports 

F vent-level  reports  consist  of  those  reports  that  are  generated  at  the  completion  of  each 
simulation  event.  An  event-level  report  provides  a single-line  output  that  indicates  the  current 
event  executing.  These  reports  are  used  to  provide  an  event-by-event  trace  of  the  How  of  the 
simulation  throughout  a particular  simulation  experiment.  Figure  110  is  an  example  of  an 
event-leve.v -report  format  "N AMI."  is  the  name  ol  the  event  routine  currently  executing.  “NOW" 
is  current  simulation  time.  “N"  is  the  identification  of  the  entity  currently  being  processed  by 
the  event.  N is  normally  an  avh  me  task  or  message  identification  number. 


* * EVENT  ROUTINE  "NAME'  AT  TIME  ' NOW'  PROCESSING  ' N' 


Figure  110.  Event- Level  Report  Format 
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b.  Sample  Period  Reports 


Sample  period  reports  consist  ol  those  reports  that  are  generated  at  the  completion  of  a 
user-specified  sample  time.  Data  are  collected  during  a period  ol  simulation  time  (sample  period! 
and  then  reports  (if  specified!  are  generated  at  the  completion  ol  that  time.  Figure  III  is  an 
example  o''  j sample  period  report  for  a local  bus.  Figure  1 1 2 is  an  example  ol  a sample  period 
report  for  a processor.  The  user  may  speedy  which  reports  are  to  be  generated. 

In  all  report  examples,  tunes  are  measured  in  seconds.  A minor  frame  is  the  user-defined 
sample  period.  A major  frame  is  a user-defined  sample  period  that  contains  an  integer  number  of 
minor  frames.  Message  numbers  are  those  identifications  assigned  by  the  system  test  data. 
Message  lengths  are  measured  in  bits  including  all  overhead  bits.  Origin  and  destination  are  the 
message  origin  and  destination  processor  identification  number.  Relative  time  of  start  is  measured 
from  the  start  of  the  minor  frame  and  bus  usage  is  measured  as  a percentage  of  total  available 
bus  bandwidth 

c.  Post-Simulation  Reports 

Post-simulation  reports  consist  of  those  summary  type  reports  that  are  generated  after  the 
completion  of  a particular  simulation  experiment.  Post-simulation  reports  provide  a concise 
summary  of  all  data  collected  throughout  the  simulation.  These  summaries  allow  rapid  evaluation 
of  simulation  results  without  massive  data  redaction.  If,  after  initial  evaluation,  it  is  necessary  to 
investigate  in  further  detail,  sample  period  or  even  event  level  reports  can  be  used.  The  user  may 
specify  explicitly  which  reports  are  to  be  generated,  even  though  data  was  collected  on  all 
entities.  Figure  I 13  is  an  example  ol  the  bus  decomposition  report.  The  bus  decomposition 
report  shows  the  relative  usage  of  the  bus  bandwidth  by  each  component  of  a message., 
Figure  114  is  an  example  of  the  bus  loading  bar  graph.  This  graph  shows  the  percentage  of  bus 
usage  during  each  sample  period.  Figure  115  ;s  an  example  of  the  bus  usage  summary  report. 
This  report  summarizes  the  performance  of  each  bus  in  the  DP.'M  system  during  the  complete 
simulation  experiment.  This  report  is  actually  a summary  of  the  sample  period  bus  activity 
reports.  Also  associated  with  the  bus  usage  summary  is  a summary  of  all  messages  transferred 
over  that  particular  bus.  Figure  I 16  is  an  example  of  the  message  usage  summary  report.  Reports 
for  each  bus  may  be  selected  by  the  user.  Figure  117  is  an  example  of  the  processor  usage  bar 
graph.  This  graph  shows  the  percentage  of  processor  usage  by  interrupt  servicing,  system 
(executive!  programs,  and  applications  programs  during  each  sample  period.  Figure  118  is  an 
example  of  the  processor  usage  summary  report.  This  report  summarizes  the  usage  of  each 
processor  in  the  DP  M system  during  the  simulation  experiment.  This  report  is  actually  a 
summary  of  the  sample  period  processor  usage  reports. 

E.  PROCESSING  ELEMENT  SIMULATION 

The  objective  ol  the  Processing  P.lement  Simulator  is  to  evaluate  the  major  hardware 
design  alternatives  ol  a PF.  In  particular,  the  Processing  Element  Simulator  is  used  to  analyze 
and  evaluate:  (!»  PF.  operations  with  respect  to  internal  program  execution  and  external  inputs: 
(2)  major  hardware  design  considerations  and  alternatives  of  the  PF.  As  such,  the  PH  Simulator 
must  simulate  the  internal  performance  of  the  PH  to  a much  finer  detail  than  was  required  b> 
the  System  Network  Simulator.  However,  a new  simulation  concept  is  not  required  by  the  PH 
Simulation:  it  is.  in  fact,  lust  a logical  extension  of  the  SNS  to  the  next  level  of  detail  (i.e..  the 
discrete  event-oriented  simulation  control  structure  is  retained  by  the  PH  Simulator). 
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Figure  112.  Sample  Period  Processor  Report 
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Figure  1 13.  Bub  Decomposition  Report 


Figure  114.  Bus  Loading  Bar  Graph 
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Figure  i 1 5.  Bus  Usage  Summary  Report 
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Figure  116.  Message  Transmission  Summers'  Report 
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Figure  1 1 7.  Processor  Usage  Bar  Graph 


Processor  Usage  Summary  Report 


Figure  119.  PE  Block  Diagram 


1 . Processing  Element  Simulator  Organization 

The  PL  Simulator  is  made  up  of  five  distinct  functional  models:  the  processor,  the 
memory,  the  I/O  interface,  the  bus  interlace,  and  the  intra-processor  element  timing  and  control. 
Figure  1 ll>  is  a block  diagram  of  the  PE  as  viewed  by  the  PH  Simulator. 

Each  of  the  event  models  that  describe  these  (unctions  is  scheduled  to  occur  at  some 
future  time  by  placing  it  on  the  simulation  Future  Event  List  (FEL).  The  FEL  is  a 
chronologically  ordered  list  that  contains  ail  future  events.  Each  event  is  then  simulated  in  its 
order  of  occurrence  in  time.  Interaction,  resource  conflict  resolution,  and  sequencing  of  events  is 
automatically  controlled  by  the  simulator  structure  and  takes  place  during  the  execution  of  the 
simulation  experiment.  Figure  120  is  an  example  of  the  sequencing  of  intra-PE  events  on  the 
FEE.  The  instruction  execution  even*  simulates  the  execution  of  one  instruction  and  schedules 
itself  at  a future  time  equal  to  the  length  ol  execution  of  the  instruction.  Any  Direct  Memory 
Access  (DMA)  transfer  event  executes  next,  effecting  a transfer  to/from  memory,  and  then 
schedules  itself  at  a future  time  equal  to  the  DMA  transfer  rate.  The  interrupt  event  causes  an 
interrupt  to  be  generated  and  may  be  rescheduled,  depending  on  the  interrupt  type.  These  events 
continue  to  be  posted  on  the  FEL.  removed  for  execution,  posted  on  the  FEL.  and  on 
throughout  the  simulation.  It  is  important  to  realize  that  it  is  not  necessary  to  be  able  to  predict 
the  order  of  occurrence  of  events  u /mori. 
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Figure  1 20.  PE  Event  Sequencing 
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Figure  121.  Instruction  Execution  Cycle  Block  Diagram 


2.  Processor  Simulation 

The  processor  model  describes  the  various  machine  registers  available  to  the  programmer 
through  the  instruction  set  the  execution  operation  of  each  processor  distinction,  the  timing  of 
each  execution  operation,  and  the  interna!  processor  interrupt  striuture.  The  set  of  simulation 
routines  that  simulate  the  processor  will  hereafter  be  referred  to  as  .lie  Instruction  Level 
Simulator  (ILS). 


a.  H.S  Inputs 

Binary  program  object  code  modules  generated  by  the  assembler  representing  either  avionic 
apphiu’ion  (unctions  or  selected  test  code  kernels  are  inputs  to  the  ILS.  The  binary  object 
modules  are  link-edited  together  by  the  PL  Simulator  monitor  to  form  an  absolute  object 
module  which  is  loading  into  a pseudo-memoiy  that  represents  the  actual  processor  memory . 
Variables  that  describe  processor  performance'  parameters  such  as  clock  speed,  memory  read, 
write  times,  memory  si/e.  etc...  are  located  in  a single  FORTRAN  C OMMON  block  to  facilitate 
modification.  To  begin  simulation,  the  program  counter  is  initialized  to  the  hardware  "GO” 
location  and  the  first  instruction  is  fetched  from  pseudo-memory  for  simulation. 


h US  Oficruliims 


['lie  ILS  luiKliun.il  operation  emulates  the  actual  processor  hardware  l lie  instruction 
eveeutiun  sequence  is  represented  in  I mure  121  lahle  2s  is  a list  ol  all  processui  iiistriutiun 
algorithms  lad)  step  m instriKtiun  execution  smiulaiiun.  as  well  as  description  ul  some  ol  the 
I OK  I KAN  routines,  will  he  described  in  detail  in  the  tollowmg  subsections 

<•  Instruction  Execution  l.vcnt 

I lie  instriKtiun  execution  event  (IIODI.V  is  the  discrete  event  that  represents  the 
o>  nrreiKe  ol  a processor  instriKtu  J execution  1 he  actual  instruction  sn..  •lution  takes  place  in 
the  instruction  execution  simulation  routine  (SMI  IKt  SMI  IK  is  described  in  the  billowing 

TABLE  2H  PROCESSOR  INSTRUCTION  SIMULATION  ALGORITHMS 
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subsection.  IFODHX  controls  any  concurrency  or  conflicts  with  other  PH  model  events.  This 
routine  verities  that  no  higher  priority  events  are  pending  at  the  current  time  and  then  calls  the 
instruction  simulation  routine.  At  the  completion  of  the  simulation  routine.  IFODHX  checks  if 
the  next  event  on  the  FI  L is  due  to  occur  before  the  next  instruction.  If  there  is  an  event 
pending,  the  IFODHX  event  is  placed  on  the  FHL.  If  there  is  no  event  pending,  simulation  time 
is  advanced,  and  the  simulation  routine  is  called  to  simulate  the  next  instruction.  This  look-ahead 
eliminates  the  unnece»sar>  placing  and  removing  of  the  IFODHX  routine  on  the  FHL.  Since  the 
majority  ot  the  PI  simulation  time  is  spent  during  instruction  simulation,  this  minor  test  results 
m a mafor  decrease  m simulation  run  time. 

d Instruction  Simulation  Routine 

I he  main  instruction  simulation  routine  (SMLTR)  contains  the  logic  to  simulate 
instruction  fetch,  operand  derivation,  and  execution.  The  first  step  in  instruction  simulation  is  to 
letch  from  pseudo-memory  the  instruction  to  be  simulated.  The  instruction  word  is  then  passed 
to  the  instruction  decode  routine  (IDHO.  IDHC  extracts  the  various  fields  from  the  instruction 
and  sets  a tlag  ( TVPhf  that  indicates  the  source  format  type.  Figure  122  shows  the  various  values 
oi  the  TYPl.  tlag  Next,  the  various  fields  of  the  instruction  are  passed  to  either  the  long  or 
short  instruction  operand  derivation  routine  (LOPDHR  or  SOPDHR).  depending  on  the  type 
instruction  format.  The  LOPDHR  and  SOPDHR  routines  compute  the  derived  operand  for  the 
instruction  based  on  the  modification  field  value.  Controi  is  then  passed  to  the  execution 
simulation  section  by  use  of  a FORTRAN-computed  GO  TO  based  upon  the  value  of  the 
instruction  opcode  Fach  ins*ruction  execution  algorithm  shares  a common  data  base  of  variables 
that  contains  such  things  as  processor  register  file,  status  word,  value  of  derived  operand,  etc.  As 


TYPE 

SOURCE  FORMAT 

KEY 

1 

op  R 

r.t 

X-0,  *-0 

2 

op  C 

r,A 

X-0,  M-2,  t-7 

3 

op  R.l 

r.t 

* 

O 

• 

X 

4 

op  R.IA 

r.t 

X-0,  M-2,  tj»7 

5 

op.D 

r.A 

X-0,  H-3,  t-0 

6 

oo.  DX 

r.A.t 

X-0,  *>3,  tfO 

7 

op 

CAW,  A 

X-l,  C-6  or  7,  r-0 

B 

op 

r.A 

X-l 

9 

LDS 

r.O.t 

X-2 

10 

SOS 

r.O.t 

X-3 

9 9 
11 

OP 

CAW.A.r 

X-l,  C*7  or  8,  rfl 

12 

op  C 

r.A, A* 

X-0,  »*2,  t-7. 
Double  Instruction 

Figure  122.  Instruction  Formal  Types 


stated  previou.lv.  a particular  algorithm  is  sdcctcil  based  upon  the  instinctual  opcode  jnd 
execution  is  performed.  At  the  completion  ot  execution  simulation,  control  is  returned  to 
IFODIX.  As  an  example,  consider  a load  instruction  with  the  direct  modification  v Inch  has  the 
following  binary  format: 


i l)  0 

U U 0 U 0 1 II 

0 0 0 

0 1 0 

X 

( 

M 

I 

R 

First.  11)1  C will  determine  that  the  instruction  is  of  the  standard  lormat.  Knowing  the  format. 
IDIC  extracts  the  various  fields  anu  stores  the  following  variables  into  the  common  data  base: 
X = 0.  (’=  I,  M = 3.  T = 0.  R = 2.  TYPI-.  = 5.  Since  the  instruction  is  of  the  standard  forma’. 
LOPDFR  is  called  to  compute  the  derived  operand  (DO).  LOPDI.R  uses  the  value  M t» 
determine  that  the  instruction  is  a direct  modification.  LOPDFR  ‘etches  the  A-field  (next  word) 
and  increments  the  IX'  Finally,  LOPDI.R  returns  the  contents  ui  the  address  pointed  to  by  the 
A-lield  as  the  DO.  The  value  of  C is  then  used  in  a computed  GO  TO  to  pass  control  to  the  load 
simulation  algorithm.  The  load  simulation  algorithm  loads  the  DO  into  the  register  specified  by 
the  value  of  R Lastly,  the  print  line  is  formatted  anil  control  is  returned  to  IFODI  X. 

The  execution  time  for  the  particular  instruction  is  computed  by  use  ot  a table  lookup 
based  upon  its  operation  code.  Any  auditional  time  required  for  the  operand  derivation  and 
special  execution  time  conditions  is  also  added.  Special  execution  time  conditions  include  such 
things  as  the  increased  time  when  a branch  is  taken  on  a condition  branch  instruction. 

e.  Interrupt  Sin  .tlation 

The  simulation  of  the  interrupt  structure  parallels  the  following  hardware  characteristics: 

( 1 1 a stimulus  tc  an  armed  or  enabled  interrupt  will  cause  a trap  to  be  simulated  using  the  data 
address  specified  by  the  originator:  (2)  a stimulus  to  an  unarmed  interrupt  will  be  remembered: 
(3)  stimuli  to  two  armed  interrupts  will  result  in  the  interrupt  of  the  highest  hardware  priority 
trapping  first:  (4)  an  interrupt  stimulus  that  occurs  during  the  execution  of  an  instruction  . ill 
occur  after  completion  of  instruction  execution.  A diagnostic  warning  message  is  printed  if  an 
interrupt  stimulus  was  present  but  could  not  trap  since  the  interrupt  w'as  not  armed.  The 
simulation  ol  the  :nterrupt  structure  of  the  computer  allows  the  following  options  in  creating 
interrupt  stimuli  to  a program  by  means  of  parametei  cards: 

specification  ol  the  interrupt  priority  and  corresponding  ‘ran  address 

specification  of  the  frequency  ot  occurrence  of  that  interrupt 

spe.it  I- at  ion  of  a tune  intetv.il  to  be  used  in  the  frequency  of  occurrence. 

In  addition  to  (-.signing  the  hardware  pnoriiy  ol  an  intern.pt  stimuli!-,  it  is  also  possible  to 
specify  the  Ire  nieitcy  and  interval  of  tn*e  a!  which  the  interrupt  stimulus  is  to  occur.  There  are 
i"ui  possible  frequency  options  that  may  be  defined 

R interrupt  to  occur  at  random  time  intervals 
I interrupt  lo  occur  ai  a fixed  lime  interval 

intc'irupl  to  occur  at  single  . ue  interval  (i.c..oniy  once  during  the  simulation) 

( 1'iieiriipi  «o  occur  . some  interval  ol  tune  alter  the  ssumg  ol  a specified  CAV. 


I-acii  of  the  above  lrequenc  can  be  associated  with  both  internal  and  external  interrupt 
stimuli.  Since  there  is  no  ccuul  distinction  made  between  an  internal  or  external  interrupt 
request,  the  simulator  does  not  require  such  a distinction.  It  should  also  be  noted  that  frequency 
type  (.'  is  used  to  form  the  amount  ol  time  required  to  acknowledge  a programmed  controlled 
I O transfer. 

The  actual  time  interval  between  simulator-generated  interrupts  is  defined  in  the  form  of  a 
time-to-mterrupt  equation.  This  interrupt-schedule  equation  enables  the  simulator  to  calculate  the 
time  the  next  interrupt  will  occur.  The  equation  field  of  the  parameter  definition  card  is  divided 
into  a mantissa  and  characteristic  to  provide  a wide  range  of  interrupt  time  internals.  The  form 
ol  the  equation  on  the  parameter  card  is 


mmmcc 


where 

innini  = the  mantissa 
cc  = the  characteristic. 

The  above  field  can  be  translated  into  the  following  equation 

mmm  X 10'“  seconds 

Interrupt  simulation  consists  of  an  interrupt  event  routine  (IN'TTNT).  an  interrupt  stimulus 
generation  loutine  (INTBLD).  an  interrupt  enabling  routine  (INTI  ST).  and  an  interrupt  event 
notice  list  structure.  The  interrupt  event  notice  list  structure  is  shown  in  Figure  123.  Only  one 
event  notice  is  required  because  the  prioriti/ation  and  ordering  are  handled  automatically  by 
INTBLD.  This  logic  and  the  use  of  the  list  structure  are  represented  by  the  functional  flow  chart 
shown  m Figure  124.  Any  instruction  simulation  that  modifies  the  processor  status  word  must 
call  INThST  to  test  it  any  interrupts  have  been  delayed  because  mask  bits  have  been  disarmed. 
INTFST  searches  the  delayed  queue  checking  for  previous  occurrence  of  newly  enabled 
interrupts  it  also  searches  the  pending  queue  for  any  pending  in.trrupt  that  has  been  missed 
previously.  In  either  ca  e.  if  an  interrupt  is  found,  it  is  rescheduleu  by  the  appropriate  call  to 
INTBLI). 

When  tiie  interrupt  event  occurs,  it  tests  if  the  interrupt  is  enabled.  If  not  enabled,  the 
event  is  placed  on  the  delayed  queue.  If  enabled,  the  trap  Hxchange  Status  and  PC  instruction 
arc  executed . using  the  address  contained  in  the  event  notice.  In  either  case,  the  next  pending 
interrupt  is  removed  from  tin  pending  queue  and  the  next  interrupt  event  notice  is  placed  on 
the  future  event  list. 

The  interrupt  simulation  scheme  just  described  has  no  constraint  on  either  the  number  of 
interrupt  levels  or  the  prior. ti/ation  scheme.  In  other  words,  the  interrupt  scheme  is  completely 
general  jnd  not  constrained  to  the  DP  M point  design. 

f.  U.S  Outputs 

The  outputs  ot  the  ll.S  consist  ot  one  print  line  indicating  the  instruction  that  was 
executed,  the  current  state  ot  the  processor,  and  the  instruction  execution  tunc  including  any 


Figure  1 23.  Interrupt  Event  Notice  List  Structure 
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Figure  1 24  Interrupt  Stimulus 
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memory  conflict  delays.  The  print  output  may  be  optionally  turned  oil  by  user  commands,  hash 
portion  of  the  output  shown  in  Figure  125  is  explained  by  the  following  short  annotation: 

Column  Label  Comments 
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instiuction 

Amount  ot  nine  mommy  used  by  autonomous  DMA  channel  during 
current  instruction 
t umulative  total  ol  Ml  +GT+!  MAT 

Instruction  execution  time  excluding  any  delay  caused  by  memory 
con  lltcts 

Cumulative  total  ol  simulation  time  (Note  all  times  in  microseconds, 
all  other  data  in  hexadecimal  ) 


Also  provided  arc  the  data  and  time  that  the  simulation  run  took  place. 

An  optional  output  of  the  ILS  ts  a histogram  which  provides  a summary  of  all  instructions 
executed  during  the  simulation.  The  summary  gives,  for  each  instruction,  the  number  of 
executions,  total  execution  time,  percentage  by  time,  and  percentage  !>.  occurrence.  Also 
provided  is  a summary  indicating  the  number  as  well  as  percentage  of  ''-bit  and  32-bit 
instructions  executed.  Figure  I 2b  is  an  example  ol  the  histogram  output. 

3.  Bus  Interface  Unit  Simulation 

The  Bus  interlace  Unit  (BUT  simulation  portion  ot  the  I’F  Simulator  consists  of  those 
event  routines  that  simulate  the  performance  ol  lb:  BIT.  The  BIT  model  is  niodularlv  structured 
as  the  integration  ol  a set  ol  Bl  l '-event  models,  each  ol  wlmh  is  a FORTRAN  subroutine 
representation  ot  a discrete  functional  operation.  I adi  event  is  modeled  in  terms  ot  tlu  ellect  of 
the  event  on  the  functional  registers  of  the  BIT  hardware.  The  models  are  driven  by  exogenous 
events  and  also  interact  with  other  PI  tuiKtional  element  models  (eg.  the  I’F  memory  I in  the 
performance  ol  particular  Blf -related  activities,  as  shown  in  I igurv  122 
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Figure  1 25.  Example  of  Instruction-Level  Simulator  Output 
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Figure  126.  Simulation  Instruction  Usage  Histogram  (Sheet  I of  2) 


Basically,  the  BIU  model  is  segregated  into  two  primary  functional  activities:  Message 
input  and  Message  Output,  fcacli  major  activity  is  then  subdivided  into  a collection  of  register 
level  events  associated  with  the  performance  of  the  activity  during  PI-  operation.  Each  event 
model  is  essentially  duplicated  lor  both  Global  and  Local  (G  LI  bus  activities,  with  minor 
deviations  occurring  m a few  event  models  where  (i  1 operational  characteristics  differ. 

a.  Bill  Simulation  Inpul  Data 

Input  message  data  lor  the  BIU  simulator  consists  ol  two  card  input  streams  arranged  in 
chronological  order  that  define  the  input  message  that  is  to  be  simulated  for  a particular 
simulation  experiment.  These  data  sets  may  be  generated  by  hand  or  may  be  an  output  of  an 
earlier  System  Network  Simulation  experiment. 

LOR  I RAN  NAM1  LIST  input  was  selected  to  allow  the  data  to  h-  self-documenting  as 
well  as  meaningful.  Table  gives  the  format  tor  the  input  message  data  sets.  Figure  1 2X  shows 
an  example  of  input  message  definition  data  lor  one  local  and  two  global  messages. 

h Bli'  Simulation  List  Structure v 

In  keeping  with  the  overall  l>P  M simulation  system  philosophy,  a series  of  predefined, 
identical  event  notice  list  structures  were  defined  to  be  used  by  all  BIU  simulation  events. 
Though  not  all  portions  ol  the  list  strictures  were  used  by  all  event  routines,  the  uniformin  ol 
the  structures  greatly  simplified  piogram  development  as  well  as  checkout 
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Figure  126.  Simulation  Instruction  Usage  Histogram  (Sheet  2 of 


Figure  127.  BIU  Functional  Model/PE  Functional  Simulation  Interface 
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Figure  I2K  BIU  Input  Mevagi  Data  Example 


TABLE  29.  BIU  SI  ULAT10N  INPUT  DATA  SPECIFICATION  FORMAT 
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bUMU.ni  = / 

b (iMI)ATA  = / Same  tneamng  as  in  local 
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f igure  1 2'<  gives  the  structure  of  the  Bit’  event  notices  IOS1MZ  is  a vector  whose 
elements  are  pointers  t o the  event  notice  Itsi  structures.  I ach  event  notice  list  structure  required 
is  del ined  at  simulation  initiation  time  and  a pointer  to  it  is  placed  in  IOSIMZ.  Defining  the 
event  notice  list  structure  helore  simulation  saves  the  overhead  required  to  dynamically  create 
and  destroy  event  notices. 

The  reserved  words  are  required  In  the  Basic  Simulation  tor  all  event  notices.  Priority  is 
used  to  resolve  memory  conflicts  lor  those  events  simulating  memory  reference.  Memory  conflict 
resolution  will  be  discussed  m the  section  on  memory  simulation.  Next  event  address,  reference 
time,  and  next  event  notice  are  used  oy  the  bus  memory  relerence  event  to  schedule  successors 
to  events  that  requested  a memory  transfer.  The  Ur  d global  llag  allows  one  event  routine  to 
simulate  both  the  Local  and  (ilohal  bus  based  upon  the  status  ol  the  flag.  The  read  write  Hag 
specifies  whether  an  event  is  requesting  a read  from  or  a write  to  memory.  Memory  data 
contains  the  data  to  be  written  to  memory,  or  the  data  returned  from  a memory  read  request. 
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Figure  129.  BIU  Simulation  Event  Notice  List  Structure 


The  pointer  to  message  data  points  to  a dynamic  memory  block  that  contains  input  message 
data.  The  current  word  being  processed  indicates  which  word  in  the  input  data  is  currently  being 
input. 


As  stated  earlier,  corresponding  to  each  BIU  event  model  described  is  one  event  routine 
that  implements  the  logic  specified  by  the  model  definition.  Kach  model  event  routine  schedules 
its  successor  even t( si  by  placing  them  on  the  future  event  list.  Concurrency,  memory  conflicts, 
and  event  delays  are  automatically  handled  by  the  Basic  Simulator  and  the  memory  simulation 
model. 


For  the  sake  of  brevity,  only  one  representative  event  routine  will  be  exampled  in  detad. 
However,  all  other  events  are  approximately  equal  in  complexity.  Figure  130  is  the  event  model 
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Figure  DO.  Data  Input  End  Event  Model 


for  the  data  input  end  event.  Numbers  in  the  following  discussion  refer  to  the  FORTRAN 
statement  numbers  in  Figure  131. 
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Figure  131.  Dum  Inpul  End  Event  Routine 
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Figure  132.  Example  of  Bus  Interface  Unit  Simulation  Output 


H!l ' Simulation  Om/jut 


TABLE  JO.  ( AH  OPERATIONS 


Operation  Read, Write 

<10  Instruction  Function  l 

tRWl 

Output  Primary  level 
Interrupt  Mask 

W 

Input  Primary  level 
Interrupt  Mask 

K 

Output  <C.  1.1  interface  Status 

\\ 

Input  (G  1.1  Interface  Status 

R 

Activate  (G  L)  Output 

U 

Output  tG  Lt  Bus  Control 

W 

Input  Present  (G  1.1  Position 

R 

Input  (G  l.t  Queue  Pointer 

R 

Input  (G  Ll  High-Priority 
Interrupts  (Level  3 '5 1 

R 

Input  <G  l.t  Low-Priority 
Intenupts  (Level  4 <>l 

R 

Enable  (G  Lt  Output 

W 

Disable  (G  Li  Output 
Internal  Operations: 

W 

•Activate  Autonomous  Transfer 

w 

Deactivate  Autonomous  Transfer 

w 

Input  ATC  Status.  Upper  Half 

R 

Input  ATC  Status.  Lower  Half 

R 

Input  Programmable  Interval 
Timer 

R 

Output  Programmable  Time 
Interval 

W 

Input  and  Deactivate  Interval 
Timer 

Externa!  Operations: 

R 

Programmed  Data  Output 

W 

Programmed  Data  Input 

K 

NOTE:  (G'l  I = (Jlobal 'Local 


r. 

The  output  of  the  BIU  simulation 
routines  is  interleaved  with  the  output  of  the 
ILS.  ‘ ach  occurrence  ol  a Bit’  event  routine 
can*  s a line  to  he  printed,  mdic -it mg  winch 
event  routine  has  occurred  and  whe’her  it  was 
processing  as  a Local  or  (ilohal  hus  as  well  as 
the  time  of  occurrence.  The  statu-  of  all 
internal  Bit-  registers  for  both  the  Lo.al  and 
(ilohal  hus  are  also  displayed  as  they  c " ist  at 
the  beginning  of  the  event. 

All  memory  translers  initiated  by  BIU 
event  routines  cause  a line  to  be  printed  at  the 
initiation  ot  the  transfer.  This  line  indicates 
which  bus  initiated  the  transfer,  whether  the 
transfer  was  a read  or  a write,  the  data,  the 
address,  and  the  time  the  transfer  was 
initiated. 

Figure  132  is  an  example  of  the  output 
generated  by  the  BIU  simulation. 

4.  I O Simulation 

The  I O simulation  section  of  the  PF 
Simulator  consists  of  those  event  routines 
necessary  to  simulate  the  performance  of  the 
autonomous  channel,  processor  controlled  I/O. 
interval  timer  operation,  and  pseudo  L'O 
operations. 

The  processor  CAW  assignments  given  in 
Table  30  provides  the  interface  between  the 
I O routines  and  the  ILS.  When  a processor 
I O instruction  is  executed,  the  CAW  and  data 
are  passed  to  a routine  that  simulates  the 
action  of  that  CAW.  The  result  of  the  CAW 
simulation  may  invoke  other  event  routines 
such  as  autonomous  channel  transfer  event  or 
acknowledge  event. 


Detailed  modeling  of  the  internal  operation  of  the  autonomous  channel  is  not  required  to 
provide  accurate  simulation.  The  only  operation  that  affects  PF  Performance  is  memory 
conflicts.  Since  memory  conflict  resolution  is  handled  automatically,  it  is  possible  to  implement 
the  functional  performance  of  the  E'O  system  without  detailed  physical  simulation  of  internal 
I/O  register  transfers. 
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The  Programmable  Interval  Timer  (PITl  is  a prt  gram-eontrolled  counter  that  generates  an 
interrupt  when  its  contents  have  been  decremented  to  a count  of  zero.  The  PIT  is  initiated  by  an 
Output  Programmable  Time  Interval  C’AW  which  inseits  a program  specified  time  interval  into 
the  counter.  The  current  value  of  the  PIT  is  read  it  any  time  by  execution  of  an  Input 
Programmable  Interval  Timer  CAW.  Execution  of  an  Input  and  Deactivate  Programmable  Interval 
Timer  CAW  will  terminate  the  PIT  activity  and  read  the  current  timer  value.  Execution  of  an 
Output  Programmable  Time  Interval  CAW  while  a previous  time  interval  is  in  progress  will  cause 
abortion  of  the  current  countdown  process  and  reinitialization  of  the  PIT.  The  PIT  has  a 
resolution  of  50  microseconds. 

The  simulator  provides  program  control  capability  via  the  pseudo-input/output  instruction 
(assembler  mnemonic  PIO).  An  unused  op-code  is  used  to  represent  the  PIO  instruction.  The 
Simulator  recognizes  the  op-code  and  performs  the  I/O  or  control  specified.  The  type  of 
operation  to  be  performed  is  indicated  by  the  R-field  of  the  PIO  instruction.  The  R-fields  and 
their  mean:ngs  are  listed  below: 

R-Fieki  Operation  Performed 

0 Restore  previous  trace  Hag 

1 Print  120  alphanumeric  characters 

2 Generate  path  usage  statistics 

t Read  HO-colurnn  card 

4 Save  trace  flag  and  start  trace 

5 Save  trace  llag  and  stop  trace 

<>  Dump 

7 Terminate  simulation 

PRIST  ( PIO  1..-U  The  contents  of  60  consecutive  pseudo-memory'  locations  (120 
alphanumeric  characters!  are  printed  on  the  next  available  line  of  the  output 
listing  when  the  simulator  processes  a PIO  I instruction.  The  address  field  of 
the  PIO  instruction  is  the  address  of  the  first  word  to  be  printed. 

USAGE  (PIO  2.  A I The  “generate  path  usage  statistics"  pseudo-command  allows 
statistics  to  he  generated  concerning  dynamic  program  flow.  Sixteen  unique 
flow  points  are  allowed  and  are  indicated  by  the  address  field  (A)  of  the 
instruction  by  the  values  0 to  15.  When  the  PIO  2.A-instruetion  is  executed, 
the  flow  point  specified  by  the  A-field  is  incremented  by  one.  At  the 
completion  of  simulation,  if  the  histogram  (H)  option  was  specified,  a report 
is  written  indicating  the  number  of  times  each  flow  point  was  executed. 

RliAI)  (PIO  ) The  character  content  of  an  80-column  card  is  stored  into  40 
consecutive  pseudo-memory  locations  when  the  simulator  processes  a PIO  3 
instruction.  The  address  field  of  the  PiOinstruction  is  the  address  where  the 
first  word  is  to  be  stored.  The  locations  will  receive  packed  ASCII  characters. 

TRACE  (PIO  4. A.  PIO  5..-1.  PIO  0,A I The  trace  is  the  primary  output  of  the 
Simulator.  The  trace  consists  of  a printed  listing  of  the  machine  conditions 
which  exist  following  the  simulation  of  each  instruction.  The  trace  output  is 
produced  after  the  execution  of  each  instruction  when  the  current  value  of 
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the  trace  flag  tTRCFIGi  is  one.  No  trace  output  is  produced  if  the  current 
value  of  TRCFLG  is  zero. 

The  value  of  TRCFLG  is  initially  set  by  the  Monitor  program.  The  value  of 
TRCFLG  may  be  changed  during  simulation  by  use  of  the  PIO  instruction. 
PIO  4 sets  the  value  of  TRCFLG  to  one.  PIO  5 sets  the  value  of  TRCFIG  to 
zero. 

It  is  also  possible  to  restore  a previous  value  to  TRCFLG  using  PIO  0.  When  a 
PIO  4 or  PIO  5 is  executed,  the  present  value  ot  TRCFLG  is  saved  at  the 
location  in  an  array  tTRFBUFi  defined  by  the  three  least  significant  bits  of 
the  address  field  of  the  PIO  instruction  before  the  new  value  is  placed  in 
TRCFLG.  The  PIOO  instruction  restores  TRCFLG  from  TRFBUF.  using  the 
three  least  significant  bits  of  the  address  field  as  an  index.  This  allows  the 
programmer  to  either  trace  or  not  trace  subroutines  and  then  restore  the  trace 
flag  to  its  previous  value  in  the  calling  routine.  Subroutines  may  be  nested  up 
to  eight  levels  deep  while  still  maintaining  individual  control  over  tracing  in 
each  subroutine. 

If  a PIO  0 is  executed  before  a HO  4 or  PIO  5 for  a given  level,  the  result  is 
indeterminate. 

DUMP  (PIO  f»,A)  The  DUMP  is  the  secondary  output  of  the  simulator.  The  DUMP 
consists  of  a printed  listing  of  the  contents  of  16  or  more  consecutive 
pseudo-memory  locations.  A DUMP  may  be  requested  in  the  following  two 
ways: 

Through  the  Monitor 

By  use  of  the  PIO  6 instruction. 

The  DUMP  requested  through  the  Monitor  is  provided  only  at  the  termination 
of  the  simulation  program.  This  DUMP  is  a listing  of  the  contents  of  all  of  the 
pseudo-memory  locations.  This  DUMP  is  accomplished  by  monitoring  the 
DUMP  flag  (DMPFLG)  after  the  completion  of  simulation.  If  DMPFLG = I. 
the  DUMP  is  provided:  if  DMPFLG  = 0.  no  DUMP  is  provided. 

The  DUMP  requested  via  the  PIO  6 instruction  allows  the  user  to  specify  a 
pointer  to  a set  of  dump  limits.  The  address  field  of  the  PIO  6 instruction  is 
used  as  the  pointer  to  a set  of  two  consecutive  memory  locations.  The  first 
memory  location  contains  the  start  address  and  the  second  location  contains 
the  stop  address  of  that  section  of  pseudo-memory  to  be  dumped. 

If  a PIO  6 instruction  references  a set  of  DUMP  limits  which  are  undefined, 
at  of  range,  or  in  an  abnormal  sequence,  all  of  pseudo-memory  is  dumped. 

Regardless  of  the  start  and  stop  limits  given,  the  DUMP  consists  of  a listing 
given  on  16  word  boundaries  in  increments  of  16  words. 

TERMIXA TE  SIMULATIOX  (PIO  7.0 1 When  a PIO  7 is  encountered  by  the 
simulator,  a normal  termination  message  is  printed  along  with  the  address  of 
the  terminating  instruction.  The  dump  Hag  is  checked,  and  DUMP  is  printed  if 
requested  before  control  is  returned  to  the  Monitor. 


5.  Memory  Simulation 


The  one  central,  shared  resource  in  the  PI  is  the  memory  . At  any  one  time,  there  may  be 
several  entities  requesting  a memory  transfer.  Consequently,  the  memory  simulation  must  provide 
for  conflict  resolution  and  subsequent  delaying  of  memory  access  to  those  requesters  of  lower 
priority.  Since  */  priori  prediction  ot  memory  conflicts  is  not  possible,  some  mechanism  must 
exist  for  resolving  conflict  within  the  difterent  memory  request  routines  themselves.  The  value  of 
the  priority  element  indicates  the  relative  ordering  of  priority  of  memory  references.  It  is  the 
responsibility  of  any  event  routine  that  simulates  a memory  reference  to  first  verify  that  no 
other  event  with  a higher  priority  is  currently  pending.  If  there  is  a higher  priority  event,  the 
lower  priority  event  must  reschedule  itself  and  relinquish  control  to  the  higher  priority  event. 
When  a memory  reference  event  finally  gains  control,  it  must  then  call  the  delay  routine 
( DP. LAY  I t«'  move  any  pending  memory  requests  on  the  FI  L between  current  simulation  time 
and  the  length  of  the  memory  transfer  to  the  end  of  the  mem«>ry  transfer.  This  delaying  of 
memory  request  events  is  because  a memory  transfer  request  can  only  be  honored  on  memory 
cycle  boundaries.  The  automatic  delaying  also  provides  a mechanism  for  studying  the  effect  of 
different  length  memory  transfer  times  for  reads  and  writes.  The  amtunt  of  time  to  delay  other 
memory  request  events,  i.e..  the  cycle  time,  is  an  argument  of  the  DI-LAY  routine. 

The  Pfc  Simulator  uses  a pseudo-memory  of  n X I o-bit  words  to  represent  the  Pfc  memory 
space.  The  value  of  n is  currently  2048  but  may  be  modified  to  allow  any  memory  si/e  up  to 
maximum  addressing  capability  of  the  Pfc  1 65.53b I.  Whenever  an  instruction  references  memory, 
the  address  actually  referenced  is  modulo  the  pseudo-memory  si/e.  Al!  memory  addresses  are 
calculated  by  means  of  a FORTRAN  routine  tADDR*  that  computes  the  actual  pseudo-memory 
address  (as  an  index t modulo  the  current  pseudo-memory  si/e.  This  ensures  a valid  address. 
Currently,  no  error  indication  is  provided  to  indicate  an  address  “out-of-range."  However,  any 
level  of  address  checking  may  be  provided  by  simply  modifying  the  ADDR  routine.  Isolation  of 
address  computation  also  allows  for  future  modeling  of  various  memory'  mixes  (ROM.  RAM. 
RMM,  etc  * whose  access  time  may  vary-. 

6.  Ancillary  Routines 

Several  ancillary  routines  were  developed  to  provide  for  ease  of  control  and  definition  of 
experiments  for  the  Processing  fclemcnt  Simulator.  These  routines  include  a monitor,  assembler, 
and  loader  link  editor.  Figure  133  shows  the  interface  between  tl.e  ancillary'  routines  and  the 
simulator. 

The  monitor  controls  the  job  flow  to  provide  user  flexibility  and  to  permit  batch 
processing  of  jobs.  The  type  of  options  that  may  be  invoked  by  the  job  cards  include: 

Assemble  a source  deck 

Load  one  or  more  object  decks 

Simulate 

Produce  a post-simulation  memory  dump 
Punch  a relocatable  object  deck 

Produce  an  instruction  usage  and  execution  flow  histogram 
Define  I/O  environment. 


Figme  133.  System  Control  Flow  Diagram 


The  assembler  accepts  source  instructions  from  cards  and  generates  assembly  listings  and 
object  modules.  The  assembler  features  include: 

Assemble  relocatable  object  programs 

Indicate  errors  and  issue  appropriate  error  messages 

Produce  assembly  listings  of  the  source  code,  object  code,  and  program  size, 
memory  storage  requirements,  and  instruction  and  data  symbols  with  a 
cross-reference  between  names  and  each  reference  to  their  u .* 

External  symbol  references 

Assembler  directives 
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Figure  134.  Avembiy  Listing  Example 
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Location  counter  origin  initiation,  static  mix  of  instructions,  data,  and  reserved 
storage  report. 

Figure  134  is  an  example  of  an  assembly  listing.  Figure  135  is  an  example  of  the  static  memory 
usage  report. 

Tlte  lnader/lmk  editor  permits  the  programmer  to  write  small  modular  programs  and  to 
then  combine  them  to  form  the  final  absolute  program  to  be  loaded  into  PE  memory.  The 
loader/tink  editor  optionally  will  also  generate  an  absolute  object  deck  suitable  for  conversion  to 
paper  tape. 

7.  Summary 

As  stated  previously,  the  objective  was  to  design,  develop,  and  use  a collection  of 
simulation  tools  to  assist  the  design  and  evaluation  of  the  DP/M  architecture.  The  programs 
developed  proved  to  be  adequate  for  the  tasks  to  be  performed.  The  System  Network  Simulator 
is  applicable  to  a wide  ra  ge  of  system  configurations  without  major  modifications  because  of  its 
flexible  data  specification  capability.  Detailed  reports  writing  capabilities  exist  that  vary  from 
event-by-event  traces  to  post-simulation  summaries.  All  report  information  is  written  so  that  it 
can  be  saved  for  later  detailed  analysis.  The  System  Network  Simulator  was  also  used  to  augment 
the  Process  Construction  study  effort.  Simulation  experiments  were  used  to  evaluate  the 
partitioning  generated  by  the  Process  Construction  algorithms.  Finally,  and  probably  most 
importantly,  the  structure  of  the  System  Network  Simulator  provides  a mechanism  for  function 
design  and  system  development  by  use  of  the  co.icept  of  top  down  design  coupled  with 
successive,  more  detailed  simulation 

The  Processing  Element  Sirrulatoi  is  a stand-alone  system  that  allows  several  levels  of 
testing  Because  of  its  sin-'lar  structure,  it  can  be  used  in  conjunction  with  the  System  Network 
Simulator  whereby  information  generated  by  the  System  Network  Simulator  is  used  to  drive  the 
Processing  Element  Simulator,  or  vice  versa.  The  PE  Simulator  can  be  used  to  study  the  effect  of 
alternative  bus  control  schemes  by  modification  to  existing  models  or  key  parameters  such  as  bus 
bit  rate,  word  size.  etc.  Similarly,  the  effect  of  the  various  key  parameters  associated  with  the 
Processing  Element  such  as  memory  speed,  clock  rate,  etc.,  can  also  be  investigated.  Finally,  tne 
System  may  be  used  as  a software  development  and  debug  tool  whereby  actual  application 
software  is  assembled  and  simulated  with  test  driver  programs.  The  detailed  reports  provided  by 
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the  Processing  Dement  Simulator  such  as  static  memory  usage  aiul  dvnaniK  instruction  usage 
histograms  allow  gathering  ot  valuable  statistical  intormation  that  can  be  used  to  rctine  the 
processing  element  instruction  set.  evaluate  the  results  of  different  algorithms,  etc. 

In  summarv.  tiie  I mutional  Simulation  System  developed  consists  ot  two  logicallv  similar 
discrete-event-oriented  simulators  designed  to  simulate  the  particular  DP  M point  design  and  also 
provide  the  llesibilitv  to  lv  used  lor  other  development  activities 


SECTION  VIII 

EXECUTIVE  DESIGN  AND  SYSTEM  OPERATION 


This  section  summarizes  the  DP/M  Executive  design  effort.  The  use  of  distributed 
Processing  Elements  (PEs)  in  the  DP/M  system  concept  dictates  the  need  for  a method  of 
scheduling  activities,  transferring  bus  messages  between  PEs  and  general  system  control.  These 
operations  are  referred  to  as  Executive  functions:  the  basic  requirements  for  a DP/M  executive 
structure  were  investigated  and  a functional  design  specification  was  developed.  Considerations 
were  given  to  design  flexibility,  expected  avionics  processing  environments,  and  adaptability  to 
different  configurations  of  PEs  distributed  on  the  DP/M  dual-level  bussing  network.  Simulation 
models  were  developed  for  use  in  the  System  Network  Simulator,  and  key  modules  were  coded 
in  PE  assembly  language  to  determine  PE  memory  requirements  and  likely  executior  limes  for 
typical  Executive  operations.  Methods  of  initializing  a network  of  distributed  f£ s were 
investigated  and  candidate  hardware  and  software  bootstrap  load  procedures  were  defined. 

A.  EXECUTIVE  DESIGN  CONSIDERATIONS 

The  role  of  the  Executive  software  within  the  context  of  the  DP/M  system  concept  is  to 
provide  a set  of  basic  control  functions  necessary  to  schedule  avionic  mission  software  routines 
and  provide  a common  communication  mechani.  n for  inter-PE  data  transfers.  The  Executive 
must  be  adaptable  to  a variety  of  possible  PE  network  configurations.  This  requirement  for 
adaptability  and  flexibility  must  be  viewed  in  light  of  the  expected  processing  capabilities  of  the 
DP/M  hardware.  Ideally,  the  Executive  should  impose  minimum  computational  overhead  for 
itself  on  the  hardware  resources  while  providing  minimum  but  necessary  control  operations  to 
ensure  satisfactory  performance  of  the  PE  network  in  accomplishing  avionic  processing  in  a 
timely  manner.  The  DP/M  Executive  must  operate  within  the  capabilities  (and  adhere  to  the 
restrictions)  of  the  system  hardware  resources  and  the  modes  of  likely  avionic  system  operation 
within  a mission.  In  addition,  the  structure  or  organization  of  real-time  avionic  programs  dictates 
that  the  Executive  provide  the  necessary  means  of  scheduling,  monitoring,  and  providing  data  set 
management  between  cooperating  processing  tasks. 

The  key  characteristics  of  the  DP/M  system  that  influence  the  Executive  design  include: 

The  homogenous  PEs  with  medium  computational  speed,  dedicated  I/O  to  an 
attached  external  device,  and  typical  program  and  data  storage  of  4 to  8K 
words  per  PE 

A dual  redundant  switchable  Global  bus  interface  per  PE 

A dedicated  Local  bus  connected  to  all  PEs  in  an  Affinity  Group  (AG) 

One  or  more  PEs  dedicated  to  a given  processing  function 

The  potenti  1 use  of  a mass  memory  device  for  initial  program  load  of  read/write 
memory 

A programmable  distributed  bus  protocol  for  Global  and  Local  bus  data  transmission 
control. 

The  limited  size  of  PE  program  and  data  memory,  combined  with  the  medium  instruction 
execution  times,  dictates  a simple  and  efficient  Executive  design.  The  possible  physical  separation 
of  PEs  in  a network  also  requires  that  the  Executive  provide  a timely  method  of  transmitting 
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datj  between  PK.  Tins  ability  to  configure  PK  in  tmil.'iple  networks  imposes  the  requirement 
that  the  DP  M Executive  structure  be  adaptable  to  various  topological  interconnections  with 
minimum  modifications  and  maximum  expectation  the  newly  created  control  software  will 
function  property  Avionic  processing  with  DP'M  results  in  a natural  partitioning  ol  system 
operations  along  functional  lines  li.e..  navigation,  weapon  delivery- ►.  The  dedication  ot  a system 
external  device  to  a PK  I O interface  also  encourages  this  functional  dedication  of  PK  to  tasks 
associated  with  a sensor  j-;d  the  algorithms  necessary  to  process  data  from  the  sensor  to  effect  a 
mission  function.  This  dedicated  nature  of  fixed  (unctions  has  a substantial  advantage  with 
respect  to  system  management.  IX'sign  is  simplified  as  is  the  control  function  when  a heavy 
emphasis  is  not  placed  on  maximum  use  ot  one  resource  < usually  the  processor  hardware).  The 
processor  hardware  is  not  the  primary  requirement  in  system  concept  formulation,  design,  anu 
application  since  the  projected  cost.  si/e.  weight,  and  power  advantages  of  the  DP  M hardware 
offer  a system  designer  this  degree  of  freedom  in  applying  processing  resources  to  Ins  problem. 

These  DP  M system  baseline  concepts  coincide  with  the  real-time  computing  characteristics 
typically  found  in  avionics  processing  systems.  Within  the  avionics  processing  environment,  every 
activity  (its  inputs,  response,  and  outputs)  is  known  and  also  planned  for.  The  worst  case  set  of 
conditions  in  terms  of  system  loading,  resource  allocation,  and  response  time  is  predictable.  This 
well-ordered  nature  of  avionics  processing  is  in  contrast  to  ground-based  computer  systems  that 
depend  upon  run-time  allocation  of  resources  to  satisfy  user  demand  input  requests  and 
maximize  system  use.  If.  for  example,  in  a ground-based  system,  dynamic  allocation  of  resources 
is  invoked  by  the  executive  control  scheme,  a simple  activity  can  suffer  undue  penalities  (its 
request  to  run  is  delayed)  while  awaiting  the  allocation  of  necessary  data  sets,  compilers, 
memory,  and  execution  time.  If  an  error  occurs  and  the  necessary  system  resources  cannot  be 
made  available,  the  requested  activity  may  be  rescheduled  with  little  penalty  to  the  user. 
However,  allocation  of  avionic  processing  resources  must  be  known,  certain,  and  timely.  The 
penalty  for  failure  can  endanger  the  success  of  the  mission,  the  aircraft,  and  the  pilot.  This 
complete  knowledge  of  the  operating  environment  and  capabilities  of  an  avionic  processing 
system  places  well-defined  bounds  on  the  functions  necessary  for  DP/M  i:\ecutive  control,  and 
provides  a clear  contrast  between  avionic  control  functions  and  multi-purpose  ground-based 
operating  systems. 

Throughout  this  executive  design  discussion,  reference  will  be  made  to  terminology  which 
arises  from  the  use  of  a directed  graph  model.  A directed  graph  consists  of  a set  of  nodes  and  a 
set  of  directed  edges  between  these  nodes.  A node  will,  he  used  to  represent  a set  of 
computations  which,  once  initiated,  can  run  to  completion  without  waiting  for  completion  of 
another  set  of  computations  also  represented  by  a node.  An  edge  from  node  i to  node  j means 
that,  upon  completion  of  the  computations  represented  by  node  i.  the  computations  by  node  j 
can  be  initiated.  The  implementation  of  a conditional  branch  in  this  model  is  accomplished  by 
an  cxclustve-OR  symbol  ( •).  Use  of  the  symbol  in  conjunction  with  node  i implies  one  of  the 
following  conditions: 

Upon  completion  of  the  computations  associated  with  node  i.  only  one  of  the  set  of 
successor  nodes  can  be  initiated. 

Completion  of  only  one  of  the  nodes  associated  with  an  incident  edge  is  necessary 
for  initiation  of  node  i. 

These  concepts  are  illustrated  in  the  example  of  Figure  136.  In  this  example,  completion 
of  node  1 indicates  that  nodes  2 and  3 can  be  initiated.  Upon  completion  of  node  2.  either  node 
4 or  node  5 can  be  initiated,  and  the  completion  of  only  one  of  these  is  sufficient  to  initiate 
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node  7.  Ntnle  X.  on  the  other  hand,  requires 
the  completion  of  both  node  <>  ai  d node  7 for 
its  initiation.  Stated  differently,  nodes  2 and  3 
are  successors  of  node  I . and  i ones  <>  and  7 
are  predecessors  of  node  X. 

With  respect  to  avionic  mission 
processing,  three  levels  of  directed  graphs  can 
he  used.  At  the  highest  level,  a node  represents 
a mission*  or  pilot-oriented  function  such  as 
navigation.  For  any  given  function,  a set  of 
nodes  or  options  may  exist  to  el  feet  the 
funetion.  These  nodes  are  referred  to  as  sub- 
functions (e.g..  navigation  modes  can  include 
inertial  navigation.  Loran.  or  doppler  naviga- 
tion). The  intent  of  the  subfunction  definition 
is  to  coincide  with  the  normal  division  and 
classification  of  avionic  computer  programs.  At 
the  lowest  level,  a subfunction  is  represented 
by  a set  of  related  tasks.  In  the  DP/M  Execu- 
tive structure,  a task  represents  an  executable 
application  software  module.  An  example  of  a 
task  within  the  Loran  subfunction  is  the 
computation  associated  with  converting  time 
difference  data  to  latitude/longitude  coordi- 
nates. These  concepts  are  illustrated  in 
Figure  137. 

The  representation  of  software  execution  sequences  via  a directed  graph  concept  has  a 
particular  advantage  within  the  DPM  concept.  The  subfunction  directed  graph  reveals  potential 
process  construction  options  in  allocating  tasks  and  program  to  Phs.  If  any  one  task  or  set  of 
tasks  must  be  partitioned  among  several  PF.s.  the  options  available  in  allocating  this  software  to 
PEs  are  clearly  defined  within  the  graph.  Data  sets  that  are  passed  from  one  task  to  another 
represent  Local  bus  messages  if  their  respective  tasks  are  not  collocated  in  the  same  PF. 
Likewise,  collocated  tasks  need  not  generate  bus  traffic  wi*h  their  data  interchanges. 

The  subfunction  directed  graph  ( Figure  137)  contains  the  necessary  information  from 
which  the  Executive  can  determine  task-scheduling  conditions  (based  upon  required  predecessor 
events)  and  inter-task  communication.  Two  types  of  directed  graphs  can  be  used  to  describe 
avionic  functions:  the  sequential  graphs  and  the  parallel  graph.  A parallel  graph  reveals  where 
within  execution  segments  of  code  parallelism  can  be  used.  A sequential  program  graph  removes 
parallelism  and  shows  transition  paths  from  one  start  node  to  an  end  node  with  multiple  nodes 
emanating  from  a single  node  having  an  associated  probability  of  transition.  Section  IX.  Process 
Construction,  discusses  in  more  detail  these  types  of  directed  graphs.  Data  derived  from  other 
types  of  graphs  can  be  used  to  derive  Executive  design  parameters:  however,  the  Affinity  Group 
(AG)  concept  is  most  effectively  used  when  parallel  graphs  are  used  for  scheduling  purposes. 
Another  desirable  feature  from  the  Executive  design  viewpoint  is  to  allow  specification  of  the 
size  of  a task  (i.e.,  number  of  instructions,  words  of  memory,  execution  time  I to  be  flexible. 
Ideally,  tasks  will  be  identified  in  a way  to  encourage  increased  system  performance.  It  is  not  the 
intent  of  the  DP/M  Executive  design  to  require  a certain  (minimum)  number  of  tasks  to  be 


EXAMPLE  OF  A DIRECTED  GRAPH 
Figure  136.  Example  of  a Directed  Graph 
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SUBf  UNCTION  INITIATE 


NOTE  A.B.C.D.E  ARE  NODES,  OR  TASKS 
OF  THE  SU9 FUNCTION  GRAPH 


Figure  137.  Directed  Graph  Representation  of  a Subfunction 


created  for  a suhfunction.  tf  a suhfunction  can  he  most  efficiently  controlled  by  the  Executive 
as  a single  task,  this  option  is  available.  If  a suhfunction  has  a potential  (or  requirement)  for 
parallelism,  the  Executive  has  a method  of  facilitating  control  of  multiple  PEs  executing  code  for 
the  different  tasks  of  the  same  subfunction.  It  follows  that,  as  avionic  subfunctions  are  assigned 
to  Pfcs.  one  PE  will  contain  the  subfunction  start-node.  This  task  would  receive  any  "subfunction 
initiate”  commands,  and  start  the  execution  cycle  for  the  given  avionic  software  algorithms. 

B.  EXECUTIVE  CONTROL  OVERVIEW 

From  these  thoughts,  two  modes  of  operation  and  control  were  considered  for  the  DP/M 
baseline  system  operation:  a tightly  coupled  system  operation  and  a loosely  coupled  system 
control  philosophy.  The  tightly  coupled  philosophy  assumes  system  order  is  to  be  directed  from 
a central  point  in  terms  of  scheduling  and  synchronisation  of  functions.  One  function,  the 


Global  Executive  (GEX)  is  given  the  responsibility  ot  scheduling  swichioni/ing-  and  ensuring 
that  the  system  will  have  a predictable  performance  and  be  capable  <>f  allocaung  necessary 
resources  to  meet  the  worst  case  demands  on  system  performance.  Several  othei  benefits  result 
from  a tightly  coupled  operating  philosophy.  The  system  can  lie  diagnosed  both  on  the  bench  in 
system  checkout  and  in  in-flight  testing.  By  imposing  a predictable  sense  ot  order,  the  system 
can  be  easily  manageable  without  undue  overhead  in  terms  of  iiardware  and  software. 

The  loosely  coupled  system  control  philosophy  assumes  that  each  subfunction  in  the 
system  is  self-scheduling  and  controlling,  thereby  minimizing  the  requirement  for  a central 
control  program.  Consequently,  each  function  broadcasts  its  data  upon  completion,  and  receiving 
functions  must  be  ready  for  the  data  when  it  comes.  In  the  event  of  random  or  unplanned 
events,  synchronization  between  subfunctions  can  become  difficult.  Such  a system  also  has 
multiple  states  and  conditions  that  could  conceivably  occui  and  cause  perturbations  in  system 
operation.  Predicting  worst  case  event  occurrences  can  be  difficult,  as  well  as  predicting  known 
states  in  the  system  for  checkout  and  testing  purposes. 

Each  of  these  operating  philosophies  had  then  merits  and  influenced  the  design  of  the 
DP/M  Executive.  A common  feature  of  both  control  schemes  is  tlie  use  of  ‘'directed  graph-like” 
predecessor/successor  conditions  for  the  scheduling  of  tasks.  The  tightly-coupled  philosophy 
assumes  a common  system  coordination  point  tliat  uses  timing  relationships  a”,  a necessary 
condition  for  process  initiation.  The  loosely  coupled  philosophy  does  not  depend  on  time,  but 
only  on  the  completion  of  program  run  time  events  (e.g..  data-set-generated,  prior  tasks  have 
completed,  etc.,  hereafter  referred  to  as  predecessor  conditions).  The  DP/M  Executive  design 
provides  both  capabilities.  The  need  for  a central  control  point  for  the  scheduling  and  synchron- 
ization of  functions  is  provided  by  the  Global  Executive  (GEX).  The  scheduling  of  tasks  within  a 
PE  solely  on  the  completion  of  prior  predecessor  conditions  (and  not  on  run  time  boundaries)  is 
the  responsibility  of  the  Local  Executive  (LEX). 

The  software  structure  capable  of  satisfying  this  dual-level  control  structure  criterion  of 
flexibility,  reliability,  transferability,  and  ease  of  testing,  is  a table-driven  Executive.  A table- 
driven  Executive  provides  a separation  system  logic  and  application  software  modules,  so 
modifications  can  be  isolated  to  individual  modules,  and  table  data  can  be  readily  modified  when 
required.  The  complete  separation  of  executive  and  applications  functions  provides  better 
reliability  and  ease  of  testing  and  maintainability.  This  scheme  also  facilitates  the  development  of 
common  modules  for  the  executive  function  in  all  Phs.  since  the  uniqueness  of  the  Executive  is 
in  its  tables.  This  also  eliminates  the  requirement  for  a special  Affinity  Group  Executive  which 
would  be  resident  in  a PE  in  an  Affinity  Group.  In  the  baseline  DP/M  system-  the  executive 
tables  in  each  PE  contain  all  the  information  pertinent  to  the  tasks  assigned  to  that  PE:  for 
example,  inputs  to  the  task,  predecessors,  successors,  outputs  double  buttering  requirements,  etc. 

In  summary,  a Global  Executive  initializes  the  system  monitors  system  pertomiance.  and 
coordinates  inter-functional  relationships.  It  schedules  on  a time  and  predecessor  basis  The  Local 
Executive  schedules  tasks  within  a PE  ( subfunction)  based  on  predecessor  relationships,  directs 
the  task  input  and  output  flow  of  information,  verifies  task  completions,  and  schedules 
Performance  Assurance  Tests  when  a PE  has  completed  all  avionics  processing  for  that  cycle.  One 
local  Executive  per  subfunction  must  return  a subfunction  complete  message  to  the  Global 
Executive.  Further  details  of  executive  design  are  discussed  in  subsequent  paragraphs.  The  GEX, 
LEX  scheduling  philosophy  is  shown  in  Figure  138.  Note  tiiat.  in  addition  to  time,  predecessors 
such  as  “pilot  initiate."  “function  complete.”  or  messages  from  other  functions  must  be  satisfied 
for  the  GEX  to  schedule  a function. 
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C.  EXECUTIVE  STRUCTURE  HIERARCHY 

The  DP/M  Executive  structure  provides  two  levels  of  control:  the  Global  Executive  (GEX) 
and  the  Local  Executive  (LEX).  Functionally,  the  GEX  assumes  the  role  of  system  monitor  and 
scheduler.  It  enforces  subfunction  interrelationships  and  is  responsible  for  system  performances 
by  coordinating  those  software  programs  required  to  effect  mission  avionic  functions  for  the 
pilot  and  aircraft.  Hie  LEX  is  a PE-oriented  function  responsible  for  sequencing  and  controlling 
tasks  assigned  to  a PE.  The  LEX  is  concerned  with  scheduling  those  tasks  assigned  to  its  PE. 
based  upon  successful  satisfaction  of  all  the  tasks  given  predecessor  conditions.  The  Executive 
control  hierarchy  for  DP/M  is  shown  in  Figure  1 39.  This  figure  does  not  represent  the  individual 
routines  within  the  Executive:  rather,  it  shows  the  inter-relationships  between  major  functions  in 
the  executive  control  hierarchy. 
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Rp«  139.  Executive  Control  Hierarchy 


The  Global  Executive  initiates  a subfunction  when  ail  the  subfunction  predecessor 
requirements  arc  satisfied  and  when  it  is  time  for  it  to  run.  These  predecessors,  in  addition  to 
start  time,  woald  be  activation  messages  from  one  or  more  other  subfunctions.  The  “initiate” 
message  is  transmit  fxl  by  the  GEX  to  the  Local  Executive  on  the  Global  bus.  The  Local 
Executive  in  the  PE  which  contains  the  start  node  of  the  subfunction  recognizes  this  message 
and.  if  all  predessors  to  that  start  mode  are  satisfied,  it  initiates  the  task.  The  task  will  execute, 
and  should  it  generate  a data  set.  it  will  call  the  LEX  for  the  disposition  of  the  data  set.  The 
LEX  takes  the  necessary  action  to  route  the  message  over  the  Local  or  Global  bus  or  returns 
control  to  the  task  immediately  should  the  message  be  for  a task  co-resident  in  the  same  PE.  The 
LEX  message  handler  always  releases  control  back  to  the  task.  When  a task  completes,  it  returns 
control  to  the  Local  Executive,  and  the  cycle  repeats.  Once  a subfunction  has  been  time  initiated 
by  the  Global  Executive,  it  will  run  to  completion  under  the  control  of  the  Local  Executivets). 
Should  an  I/O  device  He  connected  to  a PE.  it  is  the  responsibility  of  the  task  which  uses  this 
I/O  device  to  control  this  I/O  device.  This  does  not  preclude  the  existence  of  a common  I/O 
handler  routine  which  is  used  by  multiple  tasks. 

D.  FUNCTIONAL  EXECUTIVE  DESIGN  OVERVIEW 

The  following  discussion  provides  an  overview  of  the  function  provided  by  the  DP/M 
Executive.  Subsequent  paragraphs  describe  each  Executive  module  in  greater  detail  and  provide  a 
brief  summary  of  the  design  considerations  used  in  specifying  module  responsibilities.  Detailed 
flow  charts  for  each  routine  are  found  in  the  Functional  Specification  for  the  DP/M  Executive 
that  is  supplied  as  engineering  data. 

1.  LEX  Functional  Design 

The  DP/M  system  has  a homogenous  set  of  LEX  modules  in  each  PE.  The  relationship 
among  the  modules  of  the  LEX  is  shown  in  Figure  140.  Each  LEX  initiates  tasks,  honors  output 
message  requests  from  tasks,  and  routes  messages  and  data  for  the  tasks.  The  LEX  is  ^able-driven, 
thereby  maintaining  the  modular  nature  of  the  DP/'M  system  and  providing  separation  of  system 
logic  and  application  software  modules.  A Local  Executive  data  base  (or  the  LEX  tables)  in  each 
PE  contains  all  information  pertaining  to  the  correct  initialization  and  control  of  the  tasks  within 
that  PE. 

Major  routines  found  in  the  LEX  include: 

The  Bus  Interrupt  Service  Routines  which  service  interrupts  produced  by  incoming 
messages  on  the  Local  and/or  Global  bus. 

The  Task  Scheduler  composed  of  five  sub-modules  which  service  different  aspects  of 
the  scheduler  function.  The  Task  Scheduler  is  responsible  for  determining 
which  tasks  have  their  predecessor  requirements  satisfied  and  are.  hence,  ready 
to  be  given  control. 

The  Dispatcher  module  which  transfers  control  to  the  highest  priority  task  in  the 
dispatcher  queue. 

The  Output  Message  Interpretor  module  which  is  called  by  an  applications  task 
when  it  needs  output  message  service.  This  module  returns  control  to  the  task 
after  servicing  the  request. 
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Figure  140.  LEX  Module  and  Task  Interrdationshfo 


The  Message  Transmitter  Module  which  is  invoked  by  the  Output  Message  Complete 
Interrupt  from  one  of  the  bus  interfaces.  The  module  is  able  to  autonomously 
output  data  over  the  appropriate  Local  or  Global  bus  should  such  a request  be 
posted  in  its  service  queue. 

The  Interval  Timer  Service  Module  which  is  invoked  when  a hardware  Programable 
Internal  Timer  (PIT)  interrupt  occurs.  This  is  an  error  condition  indicating 
that  a task  has  taken  too  long  to  complete.  The  module  returns  an 
appropriate  status  to  the  error  monitor  module  for  disposition. 

2.  GEX  Functional  Design 

The  Global  Executive  schedules  time-dependent  subfunctions  in  the  DP/M  system.  A 
time-ordered  linked  list  provides  the  GEX  with  the  relative  times  to  schedule  every  time- 
dependent  subfunction  in  the  system.  A “go”  message  is  generated  by  the  GEX  to  a subfunction 
only  if  other  predecessor  conditions  for  the  subfunction  have  *>een  satisfied  when  it  is  time  to 
run  the  suhfunction.  The  GEX  data  base  (or  tables)  contain  all  information  pertaining  to  the 
initialization  and  control  of  all  time-dependent  subfunctions  in  the  DP/M  system.  Figure  141  is  a 
diagram  of  routines  used  by  the  Global  Executive. 

The  GEX  Scheduler  is  invoked  by  an  interrupt  from  the  PIT.  The  scheduling  algorithm 
processes  a time-ordered  linked  list  of  subfunctions  that  are  candidates  for  scheduling  by  the 
GEX  scheduler. 

All  the  LEX  modules  described  previously  form  a part  of  the  GEX.  Certain  GEX  modules 
such  as  the  Completion  Status  Monitor  and  the  Act  Kate/Deactivate  subfunction  monitor  can  be 
scheduled  by  the  LEX  in  the  Global  Executive  PE  in  the  same  manner  as  if  they  were 
application  tasks. 

The  Completion  Status  Monitor  module  of  the  GEX  is  scheduled  to  run  when  a 
completion  message  is  received  from  a subfunction.  This  module  supplies  this  information  to  the 
GEX  scheduler. 

The  Activate/ Deactivate  (subfunction)  Monitor  of  the  GEX  is  scheduled  when  an  activate/ 
deactivate  subfunction  message  is  received  over  the  Global  bus.  Like  the  Completion  Status 
Monitor,  the  activate/deactivate  monitor  supplies  this  information  to  the  GEX  scheduler. 

The  Mode  Change  Detector  module  is  scheduled  when  a mode  change  command  is  received 
over  the  Global  bus.  A mode  change  command  provides  a quick  method  of  initiating  a new  set 
of  subfunctions  such  as  might  be  involved  when  the  pilot  selects  a master  function  switch  on  a 
control  panel  and  causes  multiple  subfunctions  to  become  active. 

E.  LOCAL  EXECUTIVE  OETAILED  DESIGN  AND  OPERATION 

The  DP/M  LEX  design  provides  the  following  control  functions  for  tasks  assigned  to  a PE: 
Task  execution  initiation  (scheduling) 
input  message  processing 
Output  message  processing. 
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Figure  141.  GEX  Block  Diagram 


LEX  task  scheduling  is  based  on  satisfactory  completion  of  predecessor  conditions  for  the 
task.  The  environment  within  which  the  LEX  must  operate  is  composed  of: 

Avionic  application  tasks 

LEX  task  definition  and  control  tables 

PE  hardware  facilities. 

The  use  of  these  items  by  the  LEX  is  discussed  in  the  following  paragraphs. 

1 . Application  Task  LEX  Tables 

Every  avionic  application  task  that  is  under  LEX  control  can  be  described  via  the 
dirccted-graph  conventions  discussed  previously.  A table  structure  for  these  tasks  is  used  to 
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contain  all  information  necessary  for  the  LEX  to  control  each  task.  These  task  preamble  tables 
have  descriptive  entries  as  shown  in  Figure  142.  The  content  of  the  task  preamble  table  includes: 

Task  A Idress:  This  information  is  supplied  by  the  linkage  editor,  giving  the  address 
at  which  execution  of  the  program  code  for  this  task  is  to  begin. 

Predecessors  Remaining:  This  dynamic  entry  contains  a count  of  the  number  of 
predecessors  remaining  that  must  be  completed  before  the  task  is  ready  to 
run.  The  value  of  this  entry  is  reset  to  the  total  num  r of  predecessor  count 
when  this  entry'  is  decremented  to  zero  and  the  task  address  moved  to  the 
dispatcher  queue. 

Total  Number  of  Predecessors:  This  entry  is  static,  and  indicates  the  total  lumber  of 
predecessors  that  are  required  by  this  task.  This  value  is  used  to  reset  the 
predecessors  remaining  entry  (described  above),  when  the  task  is  moved  to  the 
dispatcher  queue. 

Total  Run  Time  of  Task:  The  value  of  this  entry  indicates  the  maximum  allowable 
time  for  this  task.  The  Executive  can  use  this  value  to  monitor  the  task’s 
time-away  from  the  Executive,  by  loading  the  PIT  with  this  value. 

Task  Iteration  Period:  This  entry  is  not  presently  used  by  the  LEX.  The  entry  is 
reserved  for  a value  which  would  indicate  the  repetition  period  of  this  task. 

Branch  Successor  Table  Pointer:  This  entry  of  the  preamble  table  is  also  unused. 
However,  in  keeping  with  the  information  content  of  the  rest  of  the  table, 
this  entry  points  to  a list  of  possible  branch  successors  generated  by  this  task. 
A branch  successor  is  a task  which  the  currently  executing  task  chooses  as  its 
successor  from  among  several  branch  successors:  this  decision  is  made  at  run 
time  by  the  currently  executing  task. 

Successor  Table  Pointer:  This  entry  is  a pointer  tc  a table  containing  the  description 
for  a number  of  tasks  which  are  eligible  to  run  upon  completion  of  this  task. 

Input  Message  List  Pointer:  This  entry  is  a pointer  to  a table  containing  the 
description  for  all  input  messages  that  are  to  be  used  by  this  task. 

Output  Message  List  Pointer:  This  entry  is  a pointer  to  a table  containing  the 
description  for  all  output  messages  that  are  to  be  output  by  this  task. 

A second  set  of  tables,  called  the  Auxiliary  Task  Preamble  Tables  (also  shown  in 
figure  142).  contain  additional  data  for  some  of  the  entries  in  the  Primary  Task  Preamble  Table. 
These  descriptive  parameters  include: 

Table  A:  Table  A is  pointed  to  by  the  branch  successor  table  pointer  m the  primary 
task  preamble  table.  It  contains  a number  of  entries  equal  to  the  number  of 
possible  brancS  successors  that  the  task  can  have,  plus  one.  The  first  word 
contains  a count  of  the  number  of  branch  successor  entries  in  this  table. 

Table  B:  Table  B is  pointed  to  by  the  successor  table  pointer  in  the  primary  task 
preamble  table.  It  contains  a number  of  entries  equal  to  the  number  of 
successor  tasks  that  are  eligible  to  run,  once  this  task  has  completed,  plus  one. 
The  first  word  contains  the  count  of  the  number  of  successor  task  entries  in 
this  table.  The  successor  task  entries  are  pointers  to  the  successor  task's 
preamble  tables.  Their  value  is  assigned  by  the  linkage  editor/loader. 


? 


TASK  ADDRESS 


PREDECESSORS  REMAINING 


TOTAL  NUMBER  OF 
PREDECESSORS 


TOTAL  RUN  TIME  OF  TASK 


TASK  (SUBFUNCTION) 
ITERATION 


BRANCH  SUCCESSOR 
TABLE  POINTER 


SUCCESSOR  TABLE  POINTER 


INPUT  MESSAGE  LIST 
POINTER 


OUTPUT  MESSAGE  LIST 
POINTER 


A - MULTIPLE  BUFFER 
INDICATOR 

C - BUFFER  USAGE  BIT 

D - MESSAGE  PREDECESSOR 
FLAG 

TASK  DESCRIPTOR  TABLE 
(1  PER  TASK) 

(1  PER  SUBFUNCTION  FOR  GEX) 


TABLE  A 

NUMBER  OF  BRANCH  SUCCESSOR 


BRANCH  SUCCESSOR 
DESCRIPTION  POINTER 


TABLE  B 


NUMBER  OF  SUCCESSORS 


SUCCESSOR  DESCRIPTION 
POINTER 


TABLE  C 


NUMBER  OF  INPUT  MESSAGES 


A 

POINTER  TO  INPUT 
BUFFER  POINTER 

•• 

•• 

TABLE  D 

C 

BUFFER  1 POINTER 

C 

BUFFER  2 POINTER 

D 

MSG  ID 

TABLE  E 


I NUMBER  OF  MESSAGES  OUTPUT 

ROUTING 

MES  ID  (10  BITS) 

•• 

Figure  142.  Task  Preamble  Tables  Used  by  LEX 


Table  (*:  Tahle  C is  pointed  to  by  the  Input  Message  List  Pointer  in  the  primary 
task  preamble  table,  it  contains  a number  of  entries  (nl  equal  to  the  number 
of  input  messages  required  hy  this  task,  plus  one.  The  first  word  contains  the 
count  of  the  number  of  input  messages.  The  next  (n)  entries  each  represent 
one  of  the  (n)  input  messages  for  this  task.  Field  “A”  is  the  multiple  buffer 
indicator.  If  “A”  is  set  to  logic  I.  it  indicates  that  the  message  has  double 
buffering  requirements  and  the  buffers  must  be  used  alternately  for  input 
data.  Buffers  are  switched  when  a task  that  uses  data  in  one  buffer  is  moved 
to  the  dispatcher  queue.  The  “Pointer  To  Input  Buffer”  entry  in  Table  C 
points  to  the  fit >t  of  three  possible  entries  relating  to  this  message  in  Table  D, 
as  described  below. 

Table  1):  A set  of  a maximum  of  three  entries  per  message  in  Table  D are  pointed  to 
by  the  corresponding  message  entry  in  Tablet".  The  first  two  entries  are 
pointers  to  the  two  buffers  into  whiclr  the  input  message  is  routed.  Field  “0” 
is  the  buffer  usage  bit.  If  set.  it  indicates  that  the  buffer  pointed  to  by  the 
word  in  which  T*  is  set  is  currently  in  use.  The  third  word  is  the  ID  of  the 
message  to  which  the  above  information  applies.  Thus,  each  input  message  is 
described  by  the  following  information  in  the  preamble  tables:  multiple  buffer 
indicator,  pointer  to  an  input  buffer  into  which  the  message  is  input,  buffer 
usage  information,  and  the  message  ID.  Note  that  if  a message  has  no  double 
buffering  requirement,  it  is  described  by  two  (instead  of  three)  words  in 
Table  D (a  pointer  to  the  input  message  buffer,  and  the  message  ID). 

Table  E:  Table  E is  pointed  to  by  the  Output  Message  List  Pointer  in  the  (primary) 
task  preamble  table.  It  contains  a number  of  entries  (n)  equal  to  the  number 
of  output  messages  generated  by  this  task,  plus  one.  The  first  word  contains  a 
count  of  the  number  of  output  messages.  Each  one  of  the  other  (n)  words 
describes  the  message  generated  by  the  task.  The  “routing”  field  indicates  the 
destination  of  the  message:  co-resident,  local,  and/or  global  bus.  The  message 
ID  field  contains  the  ID  of  this  message.  This  information  is  sufficient  for  the 
LLX  to  route  the  data  to  the  appropriate  user  as  required. 

A summary  of  the  LEX  routines  that  have  entries  in  the  task  description  tables  is  given  in 
Table  31. 

2.  LEX  Usage  of  Hardware  Resources 

Several  capabilities  provided  by  the  PE  harJware  are  used  by  the  LEX.  The  two  primary' 
features  are  the  local  and  global  bus  interfaces  : nd  the  Programmable  Interval  Timer  (PIT).  The 
Bus  Interface  Unit  provides  an  efficient  means  of  inputting  bus  messages  into  the  PF  with 
minimum  LEX  computational  overhead.  A detailed  discussion  of  this  capability  was  given  in 
Section  111.  and  key  features  that  aid  the  LEX  are  now  summarized.  Figure  143  describes  and 
shows  the  software  input  message  scheme  used  by  the  LEX. 

The  aim  of  the  input  message  processing  is  to  efficiently  correlate  input  data  messages 
with  those  recipient  tasks  that  require  this  data.  Each  message  broadcast  on  one  of  the 
communication  buses  is  composed  of  a logical  message  identification  (ID)  and  the  data  in  the 
message.  The  use  ol  logical  message  IDs  permits  the  data  to  be  broadcast  to  any  number  of  PEs 
connected  to  a bus.  Any  PF  desiring  a given  set  of  data  in  a bus  message  sets  a bit  in  its  Message 
Identify  Associative  Match  Map  (MIAViM)  that  corresponds  to  the  logical  message  ID.  The  PE 
bus  interface  also  uses  a Message  Buffer  Vector  Space  (MBVS)  which  contains  pointers  to  buffer 
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TABLE  31.  LEX  PREAMBLE  ENTRY  DESCRIPTIONS 


Table  Entry 

Users 

Description 

Task  Add  res. 

Dispatcher 

Entry  point  address  of  task  code. 

ftedecessors  Remaining 

IF.X  Scheduler 

Number  of  predecessors  remaining.  When  ui ro, 
task  is  ready  to  move  to  dispatcher  table. 

Total  Number  of  Predecessor 

LEX  Scheduler 

Number  of  different  predecessors  required  for 
this  task. 

Total  Run  Time  of  Task 

Dispatcher 

Maximum  tune  to  execute  tliis  task. 

Task  Iteration  Period 

Unused 

Period  of  repetition  ot  this  task. 

Branch  Successor  Table  fainter 

Unused 

Pointer  to  a table  containing  pointers  to  Uie 
preambles  of  run  time  branch  successors  of 
task. 

Successor  Table  Pointer 

Successor  Scanner  of 
LEX  Scheduler 

Pointer  to  a table  containing  pointers  to  the 
preambles  of  successors  of  this  tusk. 

Input  Message  List  Pointer 

Service  Module,  Input 
Message  Scanner 

Pointer  lo  a descriptor  list  for  messages  input 
to  this  task. 

Output  Message  List  Pointer 

Output  Message 
interpretor 

Pointer  to  a descriptor  list  of  messages  output 
1>>  this  task. 

Time-Ordered  List  Pointer 

GEX 

Power  to  this  task's  descriptor  list  in  the 
time-ordered  linked  list. 

Table  A 

Unused 

Contains  count  of  number  of  possible  run 
time  branch  successors  of  task  and  pointers  to 
task  preambles  for  these  tasks. 

Table  B 

Successor  Scanner 

Contains  count  of  numbci  of  successors  of 
this  task  and  pointers  to  the  preambles  for 
these  successors. 

Table  C 

Input  Message  Scanner. 
Service  Module 

Contains  count  of  number  of  messages  input 
to  task.  Flag  A indicates  if  message  requires 
multiple  buffers.  Rag  B indicates  multiple 
receipt  of  same  message  per  one  iteration  of 
the  recipient  task. 

Table  D 

Input  Message  Scanner. 
Service  Module 

Contains  pointers  to  alternate  buffers  used  by 
an  incoming  message.  Rag  C indicates 
currently  active  buffer. 

Table  fc 

Output  Message 
Interpreter 

Contau.s  count  of  number  of  messages  output 
by  task  and  routing  information  for  each 
message. 

areas  in  memory  where  input  message  data  is  *o  he  written.  Addressing  of  the  MBVS  occurs  as 
follows:  Each  incoming  message  ID  that  has  a bit  set  in  the  MIAMM  is  to  have  the  message  data 
stored  in  PE  memory.  Once  this  occurs,  the  message  ID  (value  0*1023)  is  appended  to  the 
address  of  the  first  word  in  the  MBVS  to  form  a pointer  address  to  an  entry  in  the  MBVS.  This 
entry  is  itself  a pointer  to  a data  buffer  area  in  which  the  incoming  message  is  to  be  stored. 
Three  items  are  found  in  the  buffer  area.  The  buffer  address  from  the  MBVS  points  the 
hardware  to  the  buffer  space  as  shown  in  Figure  143.  The  hardware  uses  the  length  <m)  to  cotint 
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Figure  143.  Software  Input  Message  Correlation  Scheme 
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incoming  data  words  into  the  buffer.  This  length  data  is  initially  preassigned  for  all  appropriate 
buffer  locations.  The  word  preceding  the  length  word  in  the  buffer  space  contains  a pointer  to 
the  preamble  of  the  task  that  uses  data  from  this  buffer,  if  this  word  is  zero,  it  indicates  that 
the  message  that  has  just  been  received  is  part  of  a common  data  pool,  and  has  no  successors. 
Field  B is  the  multiple-message  flag:  if  set.  “B”  indicates  that  this  message  has  been  previously 
received,  and  every  subsequent  receipt  of  this  same  message  shall  not  be  allowed  to  decrement 
the  recipient  task’>  predecessor  count.  “B"  is  reset  when  the  task  is  moved  to  the  LEX 
dispatcher  queue. 

The  other  primary  hardware  feature  of  the  bus  interface  used  by  the  LEX  is  the  BIU 
Input  Queue  Pointer  (IQP)  discussed  in  Section  .11.  Each  bus  interface  maintains  an  eight-word 
circular  queue  in  dedicated  segments  of  read/write  memory  that  is  used  to  store  the  header 
(status  and  ID)  information  for  each  message  received  by  the  PE.  The  IQP  contains  an  address  of 
the  next  entry  available  in  the  queue  (i.e.,  “IQP-l*’  is  the  address  of  the  last  complete  message 
received).  The  LEX  uses  the  IQP  to  process  input  data  required  for  scheduling  tasks  within  the 
PE. 


The  two  primary  non-bus-oriented  PE  hardware  facilities  used  by  the  LEX  are  the 
hardware  vectoring  of  interrupts  and  the  PIT.  The  PE  interrupt  structure  provides  for  the 
honoring  of  armed  interrupts  by  the  automatic  vectoring  of  the  processor  program  counter  to  an 
address  associated  with  the  given  interrupt.  This  vector  address  contains  the  derived  operand  for 
an  Exchange  Status  and  Program  Counter  instruction  (i.e.,  a new  program  counter  and  status 
word).  This  new  status  information  is  loaded  into  the  proper  PE  hardware  registers  after  the 
program  counter  and  status  word  have  been  saved.  The  PIT  is  a hardware  loadable/readable 
real-time  clock  (or  counter)  that  can  be  used  by  the  LEX  for  timing  purposes  such  as  ensuring  a 
task  executes  within  an  allowable  time  period. 

3.  Detailed  LEX  Module  Description 

The  DP/M  LEX  is  composed  of  the  following  functional  modules: 

Bus  ’.iterrupt  Service  Routines 
The  Task  Scheduler 
The  Dispatcher 

The  Output-Message  Interpreter  Module 
The  Message  Transmitter  Modules. 

A detailed  discussion  of  the  operation  of  these  routines  follows. 

a.  Bus  Interrupt  Service  Routines 

Normal  bus  interrupt  service  routines  for  both  the  Global  and  Local  buses  are  invoked 
when  an  incoming  or  outgoing  message  completes  transfer  on  its  respective  bus,  and  the  proper 
interrupt  has  been  enabled.  The  interrupt  trap  locations  initially  contain  the  address  of  the 
service  routine  and  a status  word  which  defines  the  state  of  the  other  interrupts  (masked  or 
unmasked).  When  the  normal  bus  interrupt  occurs,  PE  hardware  saves  the  current  Program 
Counter  (PC)  and  Status  Word  (SW)  in  the  interrupt  stack,  uses  the  new  status  word  from  the 
trap  location  for  machine  status,  and  branches  to  the  Bus  Interrupt  Service  Routine  as  pointed 
to  by  the  vector  in  the  trap  location. 


The  Interrupt  Service  Routine  saves  all  registers,  inputs  the  interrupt  status  word, 
determines  whether  this  interrupt  was  caused  by  an  incoming  or  outgoing  message,  and  transfers 
control  to  either  the  scheduler  or  the  message  transmitter.  In  the  normal  task  processing  mode, 
the  input  message  complete  interrupt  is  disabled  and  is  enabled  only  when  a PI.  is  in  the 
background  mode.  The  term  background  mode  is  used  within  the  context  of  the  DP/.M  to 
represent  that  time  in  which  the  PI-.  is  not  actively  executing  application  tasks.  Some  discussions 
refer  to  this  period  as  idle  time:  however,  such  time  can  be  used  for  low-priority  interruptible 
tasks.  Possible  background  tasks  include  execution  of  performance  assurance  or  diagnostic  tes* 
routines.  Any  high-priority  activity  such  as  receipt  of  an  input  message  tor  a task  can  interrupt 
and  pre-empt  execution  of  background  mode  tasks  with  no  resultant  degradation  in  system 
performance. 

b.  Task  Scheduler 

The  Task  Scheduler  is  made  up  of  five  sub-modules  which  service  different  aspects  of  the 
LtX  scheduling  function.  The  Task  Scheduler  is  responsible  for  determining  which  tasks  in  a PH. 
have  their  predecessor  requirements  satisfied  and  are.  hence,  ready  to  be  given  control.  The  Task 
Scheduler  consists  of  the  Task  Completion  F.ntry  Point  tTCFP).  Branch  .successor  Scanner 
(BSSCAN).  Successor  Scanner  (SSCANl.  Input  Message  Scanner  (IMSCAM  and  the  Scheduler 
Service  Module  ( DISPIN).  The  interrelationship  between  these  routines  is  shown  in  Figure  144. 
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Figure  144.  Task  Scheduler  Subroutine  Interrelationships 


( I )  Task  Completion  Entry  Point  (TCEP) 


The  Task  Completion  Entry  Point  segment  of  the  scheduler  is  culled  by  a completing  task 
that  is  returning  control  to  the  LEX.  The  task  passes  its  task  identification  (ID),  task  status,  and 
branch  successor  information  to  the  LKX.  The  TCHP  disables  the  PIT  (which  was  armed  by  the 
Dispatcher  module  I and  saves  the  information  that  has  been  returned  by  the  task.  It  calls  the 
Error  Monitor  routine  if  the  task  had  returned  bad  status  information,  (e.g..  the  data  it  had 
computed  was  not  valid,  a device  I/O  error  parity  occurred,  etc.).  The  TChP  is  the  “main” 
scheduler  routine  with  the  BSSCAN,  SSCAN.  and  IMSCAN  sub-modules  called  from  it,  and 
returning  control  to  it.  The  TChP  exits  to  the  Dispatcher  after  IMSCAN  returns  control  to  it. 
The  task  ID  returned  to  the  TCEP  is  in  the  form  of  a pointer  to  the  preamble  table  of  the 
returning  task.  The  branch  successor  ID  is  similarly  translated  into  a pointer  to  the  branch 
successor  task’s  preamble  table.  Thus.  LEX  modules  needing  this  information  are  able  to  use  it 
directly  without  further  computation. 

( 2 ) Branch  Successor  Scanner  ( BSSCAN  I 

The  BSSCAN  is  called  from  the  TCEP.  Its  purpose  is  to  examine  the  branch  successor  data 
returned  by  the  completing  task  to  TCEP  and  take  appropriate  action.  This  action  includes 
examining  the  Branch  Successor  Word  flag  that  has  been  returned  by  the  task.  If  a zero  flag  is 
returned,  the  completing  task  has  no  branch  successors,  and  BSSCAN  returns  to  the  TCEP.  If  the 
flag  is  non-zero,  the  completed  task  did  have  a branch  successor,  and  the  flag  is  a pointer  to  the 
preamble  table  of  the  branch  successor.  BSSCAN  uses  this  pointer  to  retrieve  the  value  of  the 
“number  of  predecessors  remaining"  entry  for  the  branch  successor  from  the  preamble  table  and 
it  decrements  this  value.  If  the  value  continues  to  be  non-zero,  it  is  stored  back  into  its  location 
in  the  preamble  table..  If  it  decrements  to  zero.  BSSCAN  calls  the  Scheduler  Service  Module. 
BSSCAN  then  makes  a subroutine  call  to  the  TCEP. 

(3)  Successor  Scanner  (SSCAN) 

When  the  BSSCAN  returns  to  the  TCEP.  the  TCEP  then  transfers  control  to  the  SSCAN. 
The  SSCAN  determines  the  successors  that  are  affected  by  the  completing  task  a*ni  takes 
appropriate  action.  A task’s  successor  information  is  found  in  the  completing  task’s  preamble 
table.  An  entry  in  the  preamble  table  points  to  an  auxiliary  preamble  table  which  contains  the 
successor  information  (LEX  Auxiliary  Task  Preamble  Table).  Each  successor  in  the  completion 
task's  table  is  represented  as  a pointer  to  each  successor  task’s  preamble  table.  Thus.  SSCAN  can 
directly  access  information  for  any  of  the  successor  tasks'  preamble  tables  without  any  further 
computations. 

SSCAN  uses  the  pointer  to  the  completing  task's  preamble  returned  by  the  completing 
task  to  find  a pointei  to  the  successor  table  (Table  B of  the  Task  Preamble  Table).  If  the  pointer 
is  /ero.  this  indicates  the  task  has  no  successors,  and  SSCAN  returns  control  to  TCEP.  If  the 
pointer  is  non-zero,  SSCAN  obtains  the  successors  preamble  address  from  the  table  pointed  to. 
Using  the  preamble  address.  SSCAN  obtains  this  successor’s  predecessor  count  (NPR7-).  SSCAN 
then  decrements  NPRZ  and.  if  the  count  decrements  to  zero.  SSCAN  calls  the  scheduler  service 
module.  If  NPRZ  is  still  non-zero,  the  value  will  be  stored  back,  and  SSCAN  looks  for  the  next 
successor,  and  continues  until  all  successors  have  been  serviced.  SSCAN  then  returns  control  to 
the  TCEP. 


(4)  Input  Message  Scanner  (I MSC AN  I 


The  Input  Message  Scanner  examines  the  FIFO  input  message  queues  (IMQi  for  messages 
input  front  the  Global  and/or  Local  bus.  It  establishes  a recipient  for  each  input  message  and 
performs  necessary  table  update  actions.  It  has  an  entry  point  from  TCEP  as  well  as  entry  points 
from  the  normal  Local  and  Global  bus  interrupt  service  routines. 

The  How  diagram  of  IMSGAN  is  shown  in  Figure  145.  When  IMSCAN  is  entered  from 
TCEP.  the  Global  bus  interface  status  is  examined  to  see  if  any  messages  have  been  received 
since  the  last  execution  of  IMSCAN.  If  it  is  determined  that  no  messages  have  arrived,  the  Local 
bus  interface  status  is  examined  for  similar  activity.  IMSCAN  exists  to  TCHP  if  no  messages  have 
come  in  over  either  bus.  The  following  paragraph  describes  the  action  of  IMSCAN  when  it 
detects  messagets)  in  the  global  IMQ.  The  action  of  IMSCAN  is  similar  when  it  detects 
message(s)  in  the  local  1MQ. 

The  first  operation  of  the  IMSCAN  is  to  obtain  the  Input  Queue  Pointer  (IQPi  from  the 
hardware  interface.  The  hardware  IQP  contains  an  address  to  a list  of  message  headers  of  bus 
data  received  and  stored  into  PE  memory.  To  facilitate  asynchronous  operation  of  bus  input 
message  processing  and  avionic  application  code  execution,  a software  queue  pointer  is  also 
maintained  by  the  IMSCAN  mouule.  While  a provision  does  exist  for  a high-priority  message  to 
interrupt  the  PF  to  gain  rapid  servicing,  the  normal  mode  of  input-message  processing  is 
non-pre-emptive  and  is  accomplished  during  time  periods  between  application  task  execution. 
After  checking  for  queue  overflow,  the  pointer  returned  from  the  interrogation  of  the  IQP  and 
the  software  maintained  current  input  queue  pointers  are  compared,  if  determined  equal,  global 
input  message  processing  is  complete  and  the  program  begins  examining  the  local  input  message 
queue. 


If  the  pointers  are  not  equal,  there  are  message  IDs  still  posted  in  the  queue  that  must  be 
serviced.  The  message  ID  is  extracted  from  the  location  pointed  to.  and  the  location  is  zeroed  to 
signify  processing  is  completed.  The  mesvige  ID  is  tl.cn  appended  to  a fixed-base  address.  This 
new  address  vector  points  to  a location  in  PE  memory'  which  contains  the  address  of  the  buffer 
pointer  to  obtain  a recipient  descriptor  word  (pointer  to  task  preamble!  associated  with  this 
message  ID.  This  descriptor  word  is  placed  in  this  location  at  system  initialization  and  can  be 
changed  only  by  the  LE.X.  The  message  descriptor  word  is  made  up  of  two  fields:  ( I > the  most 
significant  bit  (MSB)  which,  if  set  to  one.  indicates  that  this  message  has  already  arrived  at  least 
once  into  the  PE.  and  (2)  an  address  which  points  to  the  recipient  task’s  preamble  table.  If  this 
word  is  zero,  the  message  has  no  successors,  and  IMSCAN  services  the  next  message.  Messages 
that  have  no  successors  are  generally  common  data  arriving  for  use  by  several  tasks  that  have 
iteration  rates  much  faster  than  the  subfunction  using  this  data. 

If  the  MSB  of  the  recipient  descriptor  word  is  set  it  indicates  that  the  message  has  been 
used  previously  to  decrement  the  recipient  task's  predecessor  count:  the  subsequent  arrival  of 
this  same  message  leaves  the  recipient  task’s  predecessor  count  unaffected.  If  the  MSB  of  the 
recipient  descriptor  word  is  not  set.  IMSCAN  sets  the  bit  and  obtains  the  predecessor  count 
(NPRZ)  of  the  recipient  task  by  using  the  pointer  to  this  task’s  preamble  table  from  the 
recipient  descriptor  word.  IMSCAN  then  decrements  this  predecessor  count.  If  NPRZ  goes  to 
zero.  IMSCAN  calls  the  Scheduler  Service  Module  to  take  appropriate  action:  if  NPRZ  continues 
to  be  non-/ero.  this  updated  value  is  restored  into  the  appropriate  table  in  the  task's  preamble 
table,  and  IMSCAN  loops  back  to  check  for  more  messages.  When  no  more  messages  are  found. 
IMSCAN  begins  to  process  the  Local  bus  input  queue  in  the  same  manner  as  described  above. 
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After  input  queue  processing  is  complete.,  the  IMSt'AN  returns  control  to  TCEP,  if  it  was 
entered  Ire"  IVFP.  Otherwise,  it  returns  to  the  processing  in  progress  at  the  point  it  was 
interrupted. 

(5>  Scheduler  Service  Module  ( DISPIN » 

The  Scheduler  Service  Module  is  called  by  all  other  task  scheduler  submodules  (except 
Tl'FP)  when  they  have  determined  that  a task  is  ready  to  be  moved  to  the  dispatcher  queue. 
The  function  of  the  DISPIN  is  to  move  the  ready  task’s  preamble  address  to  the  dispatcher 
queue,  reset  control  Hags,  reset  the  ready  task’s  predecessor  count,  and  provide  an  alternate 
input  buffer  for  data  routed  to  this  task  if  required,  provided  all  data  input  into  the  current 
buffer  is  complete. 

The  flow  graph  of  DISPIN  is  shown  in  Figure  14ft.  The  calling  program  provides  DISPIN 
with  the  preamble  address  of  the  task  requiring  service.  Using  this  information.  DISPIN  obtains 
the  pointer  to  the  list  of  input  messages  associated  with  this  task.  If  the  input  message  table 
pointer  is  zero,  DISPIN  recognizes  that  the  task  requires  no  more  input  message  service  and 
proceeds  to  move  pertinent  task  information  to  the  dispatcher  table.  If  the  pointer  is  non-zero. 
DISPIN  obtains  the  message  count  from  the  location  pointed  to  by  the  table  pointer  and 
information  about  the  first  message  from  the  next  location  (see  Figure  1 42 >. 

DISPIN  then  determines  it  the  message  has  a requirement  for  double  buffers.  A 
requirement  for  double  buffering  of  input  message  occurs  if  the  task  using  the  message  data  does 
not  process  all  the  data  in  the  input  buffer  before  the  message  is  likely  to  be  received  a second 
time.  If  it  determines  that  the  message  requires  only  one  buffer,  it  proceeds  to  find  out  if  the 
message  is  merely  being  used  by  the  task  or  is  also  a predecessor.  If  it  is  not  a predecessor. 
DISPIN  takes  no  further  action  pertaining  to  this  message,  but  proceeds  to  service  the  next 
message.  If  the  message  is  a predecessor.  DISPIN  clears  the  multiple-message  flag  in  the  recipient 
descriptor  word  (Figure  14ft»  and  then  starts  to  service  the  next  message. 

When  a message  has  double-buffering  requirements.  DISPIN’s  decision  making  becomes  a 
little  more  complex.  First,  it  must  determine  which  buffer  is  currently  in  use.  whether  data  input 
to  the  currently  used  buffer  is  complete,  and  then  swap  buffers  accordingly.  From  this  point  on. 
its  logic  is  identical  to  that  of  the  single  buffer  case  as  described  above.  It  detennines  if  the 
message  in  question  is  merely  being  used  by  the  task  or  is  a predecessor.  If  it  is  a predecessor. 
DISPIN  clears  the  multiple-message  flag  as  described  above,  otherwise,  it  loops  back  to  process 
the  next  message. 

When  all  messages  have  been  processed  by  DISPIN,  it  proceeds  to  move  the  address  of  the 
task  being  currently  serviced  into  the  dispatcher  queue.  The  current  dispatcher  queue  position 
pointer  is  obtained  first,  and  the  task's  preamble  table  pointer  which  was  supplied  by  the  calling 
program  is  put  into  the  dispatcher  queue.  The  number  of  predecessor  locations  (NPRZ)  is  the 
reset  to  the  total  predecessors  for  this  task.  DISPIN  supp'ies  this  information  in  a register  to  the 
calling  program.  When  DISPIN  has  posted  the  task's  preamble  address  into  the  dispatcher  queue, 
it  returns  to  the  calling  program. 

c.  Dispatcher 

The  Dispatcher  is  called  from  the  TC'F.P.  The  Dispateher  transfers  control  to  the  task 
which  resides  at  the  top  of  the  Dispatcher  queue  and  provides  the  task  with  a pointer  to  a list  of 
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Figure  146.  Task  Scheduler  Service  Module  (Sheet  2 of  3) 


required  input  message  butlers.  It  also  loads  the  PIT  with  the  maximum  execution  time  for  the 
task  immediately  before  transferring  control  to  the  task:  this  enables  the  LLX  to  monitot  the 
task-'  time  away  from  the  Hxecutive.  The  Dispatcher  obtains  the  current  location  of  its  queue 
that  it  must  seiMce  from  a fixed  location  in  PI-  memory.  It  then  examines  the  contents  of  this 
location.  If  zero,  the  LLX  has  nothing  to  run.  and  control  is  transferred  to  a background  mode 
program  such  as  a PI.  built-in-test  routine.  If  the  Dispatcher  does  find  an  entry  in  this  location, 
it  saves  the  entry  and  the  new  dispatcher  queue  position  pointer.  It  then  builds  a list  of  message 
pointers,  to  messages  that  are  required  by  t„.k.  and  provides  a list  pointer  to  the  task.  Finally,  it 
loads  the  PH'  with  the  execution  time  (from  the  task's  preamble  table),  and  transfers  control  to 
the  task. 

d.  Output  Message  Interpreter  Module 

The  Output  Message  Interpreter  Module  (OMRQST)  of  the  LF.X  is  called  by  a task  when  it 
needs  output  mesage  service.  When  tasks  generate  outputs  for  other  tasks,  information  about  the 
physical  destination  of  these  outputs  is  not  required  by  the  message  generating  task.  OMRQST 
obtains  logical  header  ID  information  pertaining  to  the  output  messages  generated  by  the  task 
trout  the  task's  preamble  table,  and  accordingly  transmits  output  message  over  the  Local  bus.  the 
Global  inis,  or  both.  OMRQST  takes  no  action  for  messages  that  are  for  PL  co-resident  tasks 
other  than  return  control  to  the  task. 

The  task  calls  OMRQST  when  it  has  a data  set  ready  to  output  a message.  It  supplies  the 
billowing  information  to  the  OMRQST: 

Requester  task’s  ID  (in  the  form  of  the  task’s  preamble  pointer) 

Buffer  pointer  to  the  output  message  buffer 

Message  ID. 

OMRQST  then  obtains  the  pointer  to  the  output  message  list  by  using  the  preamble  pointer 
returned  by  the  task.  From  the  output  message  list.  OMRQST  decodes  routing  information  for 
the  message  that  needs  to  be  output.  Should  the  task  return  a message  ID  of  zero,  the  OMRQST 
decodes  this  as  being  a request  to  output  all  message  that  are  generated  by  the  requesting  task. 

After  identifying  the  proper  destination  bus  routing.  OMRQST  determines  if  the  desired 
bus  interface  is  available  for  data  output.  If  the  interface  is  available,  the  output  message  buffer 
pointer  is  sent  to  that  interface  to  initialize  an  autonomous  output  transfer.  If  the  interface  is 
busy,  the  address  ot  the  output  buffer  is  posted  into  a software  FIFO  output  queue.  Then, 
dependent  upon  whether  the  task  had  requested  the  output  of  a specific  message  or  of  all 
messages.  OMRQST  returns  or  loops  back  to  process  any  additional  messages  for  the  task  that 
must  be  output.  After  OMRQST  has  completed  processing,  it  returns  control  to  the  calling  task. 

e.  Message  Transmitter  Modules 

i he  Message  Transmitter  Modules  (MS(iXMT)  (one  each  for  the  Local  and  the  Global 
buses),  are  invoked  upon  receipt  of  the  output  message  complete  interrupt  from  the  Local  and 
the  Global  buses.  Two  identical  MSGXMT  modules  are  provided  to  service  each  of  the  two 
interrupts.  Their  only  difference  is  ihe  use  of  different  output  message  queues  and  different 
interface  1-0  commands. 


.324 


When  an  output  message  transfer  completes,  the  interrupt  vector  which  points  to  the 
message  transmitter  module  in  the  interrupt  trap  location  of  the  output  complete  interrupt  is 
automatically  loaded  into  the  program  counter  of  the  PM.  The  Bus  Interrupt  Service  module  is 
invoked  which  then  transfers  control  to  MSGXMT.  examines  the  appropriate  outrut  queue, 
obtains  buffer  pointer,  /.eros  the  location,  updates  the  queue  pointer,  and  outputs  the  buffer 
pointer  :o  the  appropriate  interface.  An  autonomous  output  message  trnasmission  is  thus 
initiated.  At  this  point  MSCiXMT  returns  to  the  PH  program  which  was  interrupted  when  the 
output  message  completed. 

F.  DETAILED  GEX  PROGRAM  DESCRIPTION 

The  Global  Executive  modules  will  most  likely  reside  in  one  or  two  designated  PHs  of  the 
DP/M  system.  The  GEX  schedules  time-dependent  subfunctions  in  the  DP/M  system.  The  GEX 
generates  a “go”  message  to  a subfunction  when  it  is  time  to  run  that  subfunction  and  other 
predecessor  conditions  have  been  satisfied. 

I . Global  Executive  Data  Base  and  Hardware  Usage 

As  with  the  LEX  control  structure,  the  Global  Executive  uses  a data  base  made  up  of 
tables  which  contain  information  required  to  correctly  initiate  and  control  subfunctions  that  are 
scheduled  by  the  GEX  and  initiate  and  control  “tasks”  which  reside  in  the  GEX  PE.  Information 
pertaining  to  the  active/deactive  status  of  subfunctions,  completion  messages,  subfunction 
iteration  periods,  output  messages,  predecessor-successor  relationships  among  tasks,  etc.,  is 
contained  in  these  tables.  Two  data  structures  are  defined  for  use  by  the  GEX:  a subfunction 
preamble  table  and  a time-ordered  link  list. 

a.  Subfunction  Preamble  Table 

The  format  of  the  subfunction  preamble  tables  is  identical  to  the  LEX  task  preamble 
tables  described  previously.  Most  entries  which  pertained  to  a task  also  pertain  to  subfunctions  in 
this  discussion  The  subfunction  preamble  table  format  is  shown  in  Figure  147,  with  the 
exception  of  a pointer  to  the  t !*'s  time-ordered  list.  Task  and  subfunction  preamble  tables 
located  in  the  GEX  PE  have  one  additional  entry:  the  pointer  to  the  task  s time-ordered  list. 
Tasks  or  subfunctions  which  are  time-scheduled  by  the  GEX  are  described  by  time-ordeted 
linked  lists  in  addition  to  their  preamble  tables.  The  pointer  that  is  being  discussed  in  this 
paragraph  points  to  this  task's  time-ordered  list.  If  the  task  (or  subfunction)  is  not  time- 
scheduled.  this  entry  is  zero. 

b.  Time-Ordered  Linked  List 

All  subfunctions  in  the  DP  M system  which  are  time-scheduled  by  the  GEX  scheduler  are 
represented  by  data  tables  which  are  elements  of  a time-ordered  linked  list  (i.e.,  list  entries  are 
arranged  with  first  low  values  followed  by  successively  higher  values).  The  words  of  this  data 
table  (shown  in  Figure  148).  when  viewed  collectively,  contain  information  necessary  to  control 
the  scheduling  ot  the  time-scheduled  subfunctions  in  the  system.  Entries  in  these  data  tables 
include: 

Clock  Update  Task  Mag:  If  this  word  is  non-zero,  this  data  item  contains 
information  pertaining  to  the  clock-update  task.  The  clock-update  task  which 
is  a periodically  scheduled  GEX  module  is  described  in  a subsequent 
paragraph. 
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Figure  148.  Time-Ordered  Linked  LBt  For  GEX  Scheduler 


Mode  Flag  This  flag,  if  set.  indicates  that  this  subfunction  requires  mode 
information  te.g..  NARBS.  RADAR.  NAV.  etc.).  It  is  used  by  the  mode 
change  detector  module  of  the  GF.X  to  post  information  into  the  “go”  output 
message  that  is  sent  by  the  GF.X  to  the  subfunction. 

PF.NAMF.S:  The  PF'NAMF.S  word  in  the  lime-ordered  linked  list  is  bit-oriented,  had) 
bit  (right  to  left)  represents  the  number  of  the  PF.  (I  to  16)  in  which  the 
starting  node  or  nodes  of  the  subfunction  is  located.  While  the  PF.NAMFS 
word  is  presently  shown  as  one  word,  mu'tiple  words  can  be  used,  depending 
upon  actual  system  requirements. 

Completed  Flag:  The  completed  Hag  is  a dynamic  entry  in  the  time-ordered  list.  It  is 
set  to  indicate  one  of  three  conditions:  (I  Mile  subfunction  associated  with 
the  table  completed  successfully  previously.  (2)  the  subfunction  associated 
with  this  table  did  not  complete.  (3)  the  subfunction  associated  w'ith  this  table 
has  been  deactivated. 

Activated  Flag:  The  activated  flag  is  a dynamic  entry  in  the  time-ordered  list.  It  is 
set  to  logic  "1"  when  a subfunction  is  considered  “active”  and  eligible  for 
being  sent  a "go”  message  by  the  GF.X. 

Preamble  Pointer:  The  preamble  poin»cr  is  a static  entry  in  the  table.  It  points  to 
the  preamble  table  associated  with  this  subfunction. 

Delta  Time:  The  Delta  Time  is  a static  entry  in  the  time-ordered  table.  Delta  Time 
indicates  the  iteration  period  of  this  subtunction. 

Time  When  Run:  This  entry  is  dynamic.  When  it  is  time  lor  a subtunction  to  run. 
the  next  time  at  which  this  subfunction  must  run  must  be  determined.  The 
“time  when  run”  entry  shall  be  updated  to  this  next  time  and  the 
time-ordered  linked  list  is  reordered  with  the  new  value  of  the  time  when  run 
entry. 

Pointer  to  Output  Message  Packet  'I his  word  is  a pointer  to  a message  packet  which 
contains  the  initiation  intormation  for  this  subfunction.  The  packet 
constitutes  the  ”go”  message  that  is  sent  by  the  GF.X  to  an  eligible 
time-dependent  subtunction. 

Pointer  to  Forward  I lenient  This  word  points  to  the  nest  highest  (in  timet  element 
in  the  time-ordered  linked  list. 

Table  32  summari/es  the  functional  description  tor  each  entiy  in  the  time-ordered  list. 

The  subtunction  preamble  table  and  time -ordered  linked  list  are  the  mechanism  used  to 
provide  a scheme  ot  centralized,  tightly  coupled  system  control  at  a global  level.  Tile 
time-ordered  link  list  provides  a means  to  ensure  periodic  sublunetioiis  are  scheduled  from  a 
common  central  timing  source.  Interdepei-  lency  among  such  suhtunctions  is  ensured  In 
controlling  the  relative  times  (to  each  othcrl  jt  which  these  subluiKtions  are  scheduled  from  the 
central  source. 

r GtiX  Hardware  i'sage 

Fhe  Programmable  Interval  Timer  (I’ll  i.  which  has  been  described  in  the  discussion  ol  the 
LI..X  as  a potential  error-detecting  mechanism  to  ensure  that  application  programs  are  completed 
on  tune,  is  used  in  the  Gl  X to  derive  the  timing  information  on  which  the  (»l  X scheduling 
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algouthm  works..  A software  clock  is  maintained  in  conjunction  with  the  GEX  timer.  Whenever  a 
PIT  interrupt  occurs  indicating  that  it  is  time  for  a subfunction  to  run,  this  software  clock  is 
ipdated  to  show  the  most  recent  time  in  the  future  at  which  the  next  subfunction  will  be 
scheduled  by  the  GEX.  Since  the  time  relationship  among  subfunctions  and  their  periodicity  is 
predetermined  for  an  avionics  environment,  a map  can  be  constructed  and  input  as  a data  base 
of  a time-ordered  linked  lists  to  the  GEX  at  system  initialization.  This  map  shows  the  relative 
time  of  start  of  each  subfunction  and  its  periodicity.  The  GEX  scheduling  algorithm  continually 
updates  this  map  during  system  operation.  It  in  effect  simulates  synchronized  hardware  in  that  it 
always  tries  to  schedule  all  subfunctions  that  appear  in  the  time  map.  Overhead  is  greatly 
reduced  by  sending  “go"  or  schedule  messages  only  to  subfunctions  that  are  active  during  a 
mission  phase. 

When  the  system  is  initialized  (see  Subsection  VIII.J),  the  GEX  scheduling  algorithm  is 
given  control  by  the  initialization  program.  As  stated  previously,  it  tries  to  schedule  all  the 
time-dependent  subfunctions  that  hav»*  been  defined  in  the  time-ordered  linked  list,  but  sends  go 
messages  only  to  those  that  have  been  set  active  by  the  process  constructor  at  system  definition 
time.  For  example,  the  pilot  console  application  program  could  be  among  those  set  active  at 
initialization.  This  program  could  in  turn  set  up  other  active  subfunctions  and  the  Global 
Executive  will  then  send  out  more  “go”  messages  to  activate  subfunctions  as  instructed  by  the 
pilot.  Alternatively,  subfunctions  can  in  turn  activate  other  subfunctions.  The  succeeding 
paragraphs  describe  each  GEX  module  in  detail. 


TABLE  32.  GEX  TIME-ORDERED  LINKED  UST  ENTRY  DESCRIPTION 


Table  Entry 

Descriptor 

Clock  update  task  flag 

This  flag  if  set  indicates  that  this  list  is  for  the  clock 
update  task  which  is  run  periodically  to  reset  the 
software  clock,  and  time  when  run  for  each  subfunction 

Mode  flag 

indicates  that  this  subfunction  requires  mode  type 
information 

Completed  flag 

Indicates  that  this  subfunction  completed  previously 

Activated  flag 

Indicates  that  this  subfunction  is  active  and  eligible 
for  scheduling 

Pramble  pointer 

Pointer  to  preamble  for  tills  subfunction 

Delta  time 

Iteration  period  for  the  subfunction 

Time  when  run 

Time  at  which  this  subfunction  must  run 

Planter  to  output 
message  packet 

Message  packet  which  must  be  output  to  initiate  this 
subfunction 

Pointer  to  forward 
element 

Points  to  next  list  entry'  in  time-ordered  linked  list 
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The  GKX  is  composed  of  the  followin.;  mtMhilcs: 

Scheduler 
Clock  Update  task 

LtX  functions  associated  with  the  Gl-X  Pi- 
Message  Gut  put  Modide 
Activate/Deactivate  Monitor 
Completion  Status  Monitor 
Mode  Change  IXtector  Module 

2.  Scheduler  <GLXS(Htl» 

The  GKX  Scheduler  is  invoked  hy  an  interrupt  trom  the  !*n,  '.rammahle  Interval  Timer.  The 
GKX  scheduling  algorithm  is  dependent  on  time-ordered  linked  list  which  has  been  described  in  a 
previous  paragraph.  The  flow  graph  diagram  of  the  Scheduler  is  shown  in  Figure  I4‘>.  As  soon  as 
GHXSCHI-I)  is  entered,  the  PIT  is  loaded  with  a large  value  so  the  time  spent  in  the  GhXSCHI  D 
can  be  measured. 

The  Scheduler  fetches  the  pointer  to  the  first  element  of  the  time-ordered  list  of 
subfunction  activation  times.  It  then  examines  the  first  word  of  this  initial  element.  If  the  word 
is  non-zero,  the  subfunction  which  must  be  scheduled  is  the  clock  update  task  and  control  is 
transferred  to  this  module  of  the  Gl-X.  If  the  first  word  is  zero,  the  program  checks  whether  the 
subfunction  that  must  be  scheduled  had  completed  successfully  the  last  time  it  ran.  or  if  the 
subfunction  has  been  aborted  for  some  reason.  In  the  lormer  case,  the  program  branches  to  an 
error  routine  and  in  the  latter  case*,  the  program  bypasses  several  other  checks  and  proceeds  to 
update  the  time-ordered  list. 

The  program  next  examines  the  word  which  specifies  whether  the  subfunction  is  active.  If 
the  subfunction  is  inactive,  the  program  ugai”  bypasses  several  other  checks  and  proceeds  to 
update  the  time-ordered  list.  Otherwise,  the  (>o.gram  obtains  a pointer  to  the  subfunction 
preamble  pointer  from  the  subfunction's  time-ordered  element,  and  determines  if  all  the 
subfunction's  other  predecessor  conditions  have  been  satisfied.  If  all  their  conditions  have  been 
satisfied.;  GKXSCHU)  requests  that  a "go"  message  be  output  over  the  Global  bus  to  the  PI:  in 
which  this  initial  task  of  the  subfunction  resides.  If  the  subfunction  had  any  input  messages. 
GKXSCIII  I)  requests  the  LI- X scheduler  service  module.  If  the  subfunction  is  being  scheduled 
for  the  first  time  and  has  dependent  sublunclions.  Gl  XSC'III  I)  activates  these  dependent 
subfunctions  also.  The  next  Gl  XSCHI  U task  is  to  update  the  run  time  of  the  subfunction  which 
was  just  scheduled  and  reorder  its  table  within  the  time-ordered  list.  After  the  time-ordered  list 
has  been  updated,  the  time  to  run  is  obtained  from  the  element  of  the  subfunction  which  is  now 
at  the  top  ol  the  time-ordered  list.  The  clock  is  updated  to  reflect  this  new  value.  Thus,  the 
clock  contains  the  tune  at  which  the  next  subfunction  shall  run.  The  program  then  reads  the  PIT 
and  determines  how  much  real  time  it  has  consumed.  The  net  time  remaining  to  the  scheduling 
of  the  next  subliinction  is  dt  teruuned  and  if  the  result  is  positive  the  PIT  is  loaded  with  this 
value.  The  program  now  restores  the  original  state  of  the  PI  and  returns  to  the  program  location 
which  the  PIT  interrupted. 
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Figure  149.  GEX  Scheduler  Flow  Chart  (Sheet  1 of  S > 
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Figure  149.  GEX  Scheduler  Flow  Chart  (Sheet  2 of  5) 
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Figure  149.  GEX  Scheduler  Flow  Chart  (Sheet  4 of  5( 


If  the  scheduler  determines  that  the  time  to  schedule  a subfunction  has  passed,  it  notes 
the  “slippage"  and  generates  an  interrupt  by  forcing  the  PIT  to  a zero  value  immediately 
(causing  an  intenupt)  so  that  a “go”  message  can  be  generated  as  soon  as  possible.  The  program 
also  supplies  the  “slippage"  information  to  the  subfunction  with  the  “go”  message.  In  this  case, 
the  GEXSCHED  shall  go  through  all  the  processes  described  above,  until  it  can  restore  the 
original  state  of  the  PE.  and  then  return  to  the  program  location  which  was  interrupted  as 
described  above. 


3.  Clock  Update  Task 

The  Clock  Update  Task  is  time-scheduled  by  the  GF.X  at  a given  period.  To  prevent  an 
overflow  from  occurring,  the  clock  update  task  is  responsible  for  devaluing  the  time-to-run 
software  clocks  associated  with  each  one  of  the  time-ordered  list  elements.  The  count  of  the 
total  number  of  time-ordered  list  elements  is  obtained,  and  a constant  value  is  subtracted  from 
each  one  of  the  run  time  software  clocks  associated  with  each  list  element.  The  software  clock 
which  is  maintained  by  the  schedu'-r  is  also  devalued  in  the  same  manner.  When  these  duties  are 
completed,  the  Clock  Update  Task  returns  control  to  the  scheduler,  and  the  scheduler  proceeds 
with  updating  the  time-ordered  list. 

4.  LEX  Routines  in  GEX 

The  LEX  in  the  Global  Executive  PE  performs  all  functions  that  have  been  assigned  to  the 
LEX  m the  DP/\1  system.  In  particular,  the  LEX  is  responsible  for  scheduling  the  two  GEX 
modules:  Activate/Deactivate  (subfunction)  Monitor  and  the  Completion  Status  Monitor. 
Messages  coming  in  to  the  Global  Executive,  and  for  the  activate/deactivate  and  completion 
status  tasks  are  recognized  by  the  LEX  Bus  Interrupt  Service  module..  The  LEX  establishes  the 
correlation  between  these  incoming  messages  and  the  recipient  GEX  modules  and,  should  their 
predecessor  conditions  be  satisfied,  the  LEX  schedules  these  GEX  modules  in  the  same  way  as 
application  tasks. 

5.  Message  Output  Module 

The  Message  Output  Module  in  the  GEX  is  responsible  for  transmitting  messages  over  the 
Global  bus.  The  module  is  similar  to  the  Output  Message  Interpreter  Module  of  the  LEX. 
However,  since  most  GEX  messages  are  transmitted  over  the  global  communication  bus.  it  is 
more  efficient  to  define  and  implement  a special  module  by  eliminating  unnecessary  local  bus 
interface  program  code. 

Any  GEX  module  which  requires  message  output  service  calls  the  Message  Output  Module 
with  the  pointer  to  the  message  which  must  be  output.  The  Message  Output  Module  checks  to 
see  if  the  Global  bus  interface  is  busy.  If  it  is.  it  posts  the  pointer  to  the  output  message  into  a 
software  FIFO  cueue  which  is  examined  by  the  Message  Transmitter  when  an  output  completes 
its  bus  transfer,  if  the  interface  is  idle,  the  Message  Output  Module  initiates  an  autonomous 
transfer  over  the  Global  bus,  and  returns  control  to  the  calling  GEX  module. 

6.  Activate/Deactivate  Monitor 

The  Activate/ Deactivate  (subfunction)  Monitor  is  scheduled  (put  into  the  dispatcher 
queue)  by  the  LEX.  when  an  activate/deactivate  subfunction  message  is  received  over  the  Global 
bus  from  a system  decision-makmg  entity  such  as  the  pilot  or  a master  subfunction.  From  the 


data  base  available  to  it,  the  LEX  determines  that  the  recipient  of  the  activate/deactivate  message 
is  an  activate/deactivate  module  (task).  The  LEX  decrements  the  modules  predecessor  count  until 
it  goes  to  zero  and  thus,  the  LEX  can  schedule  this  “task." 

When  the  Activate/Deactivate  Monitor  is  given  control  by  the  LhX,  the  pointer  to  the 
input  buffer  list  is  provided  by  the  LEX  to  the  “task."  The  first  three  data  words  of  the 
input-message  contains  the  activate  subfunction  information  and  the  next  three  words  contain 
deactivate  information.  Each  bit  in  these  words  corresponds  to  a system  subfunction.  A bit  that 
is  set  implies  the  subfunction  is  to  be  activated/deactivated,  while  a bit  that  is  a zero  represent.-  a 
noneffected  function.  The  task  examine.*  the  first  data  word  from  the  buffer,  and  if  the  task 
determines  that  the  first  data  word  is  zero,  it  then  examines  the  next  word.  If  the  data  word  is 
not  zero,  the  task  examines  each  bit  in  the  data  word  and.  hence,  determines  which  subfunction 
needs  to  be  activated. 

When  it  has  made  the  determination  of  which  subfunctions  are  to  be  activated,  it  obtains  a 
pointer  to  this  subfunction’s  preamble  from  a table.  It  then  uses  the  preamble  to  obtain  a 
pointer  to  the  subfunction’s  scheduler  time-ordered  list.  The  program  then  sets  the  active  flag  in 
the  corresponding  element  in  the  time  ordered  list.  When  this  GF.X  module  has  serviced  all  three 
“activate”  words,  it  begins  servicing  the  three  "deactivate"  words  in  the  same  manner.  It 
examines  each  bit,  associates  a subfunction  with  each  deactivate  bit  set  in  the  data  word,  and 
sets  the  deactivate  flag  in  the  subfunction  element  in  the  time-ordered  iist.  When  it  has 
completed  its  processing,  the  Activate/Deactivate  Monitor  returns  control  to  the  TCEP  of  the 
LEX  scheduler. 

This  capability  to  activate/deactivate  sets  of  subfunctions  with  one  Executive  routine 
provides  a method  of  controlling  groups  of  subfunctions.  Note  this  activation/deactivation 
provides  an  orderly  way  of  altering  the  system  state  since  only  the  GEX  scheduler  is  allowed  to 
initiate  subfunctions.  All  subfunctions  not  specifically  addressed  by  the  activate, 'deactivate 
command  remain  in  their  present  state  (i.e.,  activate  functions  remain  active  and  inactive 
functions  remain  dormant). 


7.  Completion  Status  Monitor 

The  Completion  Status  Monitor  module  of  the  GEX  is  scheduled  (put  into  the  dispatcher 
queue)  by  the  LEX.  when  a subfunnetion  complete  message  is  received  in  the  Global  Executive 
PE.  When  the  LEX  recognizes  the  input  message,  it  correlates  it  to  the  completion  status 
monitor  “task"  which  it  then  schedules.  The  incoming  message  contains  a pointer  to  an  entry  in 
the  completing  subfunction’s  preamble  table.  When  the  LEX  transfers  control  to  the  Completion 
Status  Monitor  module,  it  supplies  a pointer  to  the  input  message  buffer  pointer  list.  The 
Completion  Status  Monitor  uses  this  information  to  obtain  the  completing  subfunctions  preamble 
pointer  in  the  GEX  PE.  Using  the  subfunction  preamble  pointer,  the  Completion  Status  Monitor 
obtains  the  subfunction’s  element  in  the  time-ordered  list  and  sets  the  completion  status  bit. 

Status  Monitor  has  completed  when  it  returns  control  to  the  TCEP  of  the  LEX  scheduler 
in  the  GEX  PE. 

8.  Mode  Change  Detector 

The  Mode  Change  Detector  module  of  the  GEX  is  scheduled  (put  into  the  dispatcher 
queue)  by  the  LEX,  when  a mode  change  message  is  received  in  the  Global  Executive  PE.  When 


the  LEX  recognizes  the  input  message,  it  correlates  it  to  the  Mode  Change  Detector  "task” 
which  it  then  schedules.  The  incoming  message  contains  mode  type  information  for  the  aircraft 
mission.  A mode  change  is  associated  with  a state  change  in  certain  subfunctions  in  the  system.. 
For  example,  a primary  sensing  device  can  be  determined  to  be  faulty  and  the  subfunction  must 
change  its  operating  mode  to  use  data  from  an  alternate  device.  This  mode  change  action  is 
ecv.valent  to  altering  the  flow  (i.e..  branch  successors)  of  the  subfunction  lattice  without 
impacting  the  GEX  scheduling  pattern.  When  the  LEX  transfers  control  to  this  module,  it  passes 
a pointer  to  the  incoming  message  buffer  pointer  list  to  the  module.  The  Mode  Change  Detector 
module  scans  the  subfunctions  of  the  time-ordered  list  that  require  mode  type  information.  It 
then  obtains  the  “go”  output  message  pointer  for  such  elements  and  inserts  the  mode  type 
information  into  the  output  message.  The  Mode  Change  Detector  module  returns  control  to  the 
TCEP  of  the  LEX  scheduler. 

G.  SAMPLE  ILLUSTRATION  OF  LEX,  GEX  OPERATION 

To  illustrate  the  operational  relationship  between  the  C«EX  and  LEX.  an  example  is 
presented  based  upon  a simple  configuration  of  avionics  subfunctions.  Figure  150  is  a 
directed-graph  representation  of  a hypothetical  avionics  subfunction  to  be  used  in  this  example. 
The  subfunction  will  be  assigned  to  each  of  two  PEs  in  two  PE  Affinity  Groups.  The  other 
Affinity  Group  in  this  system  will  control  the  pilot’s  console.  The  system  consists  of  three 
Affinity  Groups,  with  one.  two.  and  one  PEs  per  Affinity  Group,  respectively.  The  Global 
Executive  is  resident  in  one  PE,  the  Local  Executive  is  resident  in  each  of  the  other  three  PEs. 
The  avionics  subfunction  identified  by  the  directed  graph  in  Figure  151  is  in  AG2.  A pilot's 
console  interpretive  program  is  in  AG3.  The  relationship  among  the  various  executive  modules 
and  tasks  is  shown  in  a time  line  in  Figure  152. 

At  system  startup,  the  GEX  tries  to  time-schedule  the  function  in  AG2  and  the  function 
in  ACL  Only  AG3  had  its  activate  message  programmed  into  the  GEX  scheduler  table,  so  when 
AG3  is  run.  an  initiation  message  is  sent  to  the  PE  in  AG3.  and  the  pilot  console  interface 
program  is  activated.  If  the  pilot  wants  the  function  in  AG2  to  run.  he  depresses  a button.  This 
action  is  interpreted  by  the  pilot's  console  program  task  in  AG3.  This  task  requests  that  it  has  a 
message  to  output  by  calling  the  Output  Message  Interpreter  Module  of  its  LEX.  This  message  is 
then  sent  over  the  Global  bus  and  is  input  by  the  global  bus  interface  of  the  GEX  PE.  The  Input 
Message  Scanner  submodule  ot  the  LEX  in  the  GEX  PE!  finds  this  message  in  the  GEX  PEs  input 


GLOBAL 

BUS 


AVIONIC  SUB-FUNCTION 
ASSIGNED  TO  THIS  AG 


Figure  150.  Hypothetical  DP/M  System 
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Figure  151.  Hypothetical  Directed  Graph  of  Subfunction  in  Affinity  Group  2 (AG2) 


queue,  and  decrements  the  predecessor  count  of  the  recipient  subfunction  (i.e..  for  the 
subfunction  in  AG2l  in  the  GEX  PE.  When  it  is  time  to  again  schedule  subfunction  AG2,  the 
GEX  Scheduler  finds  the  suhfunction  active  and  generates  an  initiate  message  for  the  subfunction 
in  AG2  over  the  Global  bus.  The  interface  hardware  in  PEI  will  recognize  this  message  by 
associative  matching,  the  message  ID  will  be  posted  into  the  input  queue  by  hardware,  and  the 
message  will  be  routed  to  an  appropriate  buffer.  When  the  Input  Message  Scanner  submodule  of 
the  scheduler  finds  that  the  input  message  just  received  is  a predecessor  for  the  task  A in  the 
task's  preamble  table,  it  decrements  the  predecessor  count  and  moves  A to  the  dispatcher  table 
because  its  predecessor  count  is  now  zero.  The  Input  Message  Scanner  will  look  again  into  the 
input  queue  and  find  it  empty,  so  it  will  transfer  control  to  the  Dispatcher.  The  Dispatcher  will 
find  that  task  A is  at  the  top-most  entry  in  the  task-ready  queue  and  transfer  control  to  it. 

When  task  A runs,  it  generates  two  sets  of  messages:  one  for  task  (’  which  is  resident  and 
the  other  for  ta>k  B in  PE2.  Suppose  A generates  a message  for  B first.  Then  it  will  call  the 
Output  Message  Interpreter  Module,  which  will  determine  that  this  message  is  for  a 
non-co-resident  task  and  is  to  be  sent  on  the  Local  bus.  It  therefore  posts  an  output  request  in 
the  output  message  queue  and  simulates  an  output  message  complete  interrupt,  so  the  Message 
Transmitter  Module  can  initiate  the  message  transfer  and  return  to  A.  The  LEX  in  PE2 
recogni/es  the  message,  finds  that  it  is  predecessor  to  task  B.  and  decrements  B's  predecessor 
count.  It  finds  that  it  is  zero  anti  the  process  is  repeated  as  described  for  task  A above. 

When  task  A generates  a message  for  task  t’.  it  once  again  calls  the  Output  Message 
Interpreter  Module.  The  latter  determines  that  the  message  is  for  a co-resident  task  and  simply 
returns  control  to  task  A (which  has  not  yet  completed).  When  A completes,  it  returns  to  the 


LEX  Scheduler  at  its  task  completion  entry  point.  The  Successor  Scanner  looks  at  Vs  preamble, 
finds  A’s  successors  (viz.,  C)  and  decrements  C’s  predecessor  count.  It  finds  that  it  is  zero,  so  it 
moves  C to  the  Dispatcher  table.  The  input  message  scanner  then  looks  to  see  if  any  input 
messages  have  come  over  the  bus.  It  finds  that  the  bus  input  queue  is  zero,  so  it  transfers  control 
to  the  Dispatcher.  The  Dispatcher  transfers  control  to  task  C.  Tasks  D.  E.  F.  and  G are  scheduled 
similarly.  Note  that  node  A was  the  only  one  that  was  time-scheduled.  Control  passed  to  the 
other  nodes  as  their  predecessor  relationships  were  satisfied. 

A special  section  of  code  which  indicates  “end  of  subfunction'’  is  appended  to  the  last 
node  (viz.,  G).  Thus,  when  G completes,  it  will  generate  this  special  message.  The  LEX  scheduler 
will  determine  from  the  preamble  table  that  this  is  a non-co-resident  message  for  the  Global  bus, 
and  ».dls  the  Output  Message  Interpreter,  which  then  will  direct  the  Message  Transmitter  to  send 
out  this  message.  The  Global  Executive  will  receive  this  message  and  examine  if  the  subfunction 
completed  its  allocated  time.  When  the  subfunction  in  AG2  is  to  run  again,  the  GEX  will  check 
if  it  is  still  active  and  the  cycle  will  repeat. 

H.  SYSTEM  OPERATION  CONSIDERATIONS/OBSERVATIONS 

This  subsection  discusses  certain  key  areas  that  were  considered  in  the  design  of  the 
various  DP/M  Executive  modules.  Most  all  areas  that  were  deemed  critical  to  the  satisfactory 
operation  of  the  system  were  implemented  in  the  actual  design  ot  ihe  execute  modules.  Other 
areas  were  analyzed  in  terms  of  their  effects  on  the  baseline  executive  design,  and  it  was 
determined  that  many  of  the  probable  DP/M  processing  activities  can  be  accommodated  with  tne 
baseline  executive.  Some  of  the  pertinent  observations  during  and  after  the  functional  design  are 
discussed  in  the  following  paragraphs. 

The  concept  of  localized  dedicated  processing  adopted  for  the  DP/M  system  allowed  for 
much  simplification  of  Local  Executive  code.  The  dedication  of  PEs  to  subfunctions  or  of  a 
number  of  subfunctions  of  equal  scheduling  priority  eliminates  the  need  for  implementing  a 
pre-emptive  scheduler  in  the  Local  Executive  design.  Thus,  in  the  normal  operating  mode,  all 
application  programs  are  allowed  to  process  to  completion.  Application  programs  would  be 
interrupted  only  upon  the  occurrence  of  high-priority  error  detection/recovery  events.  The 
dedicated  processing  concept  also  allowed  that  the  responsibility  of  I/O  handling  be  assigned  to 
an  application  program  responsible  for  processing  data  from  that  I/O.  rather  than  to  the 
Executive,  thus,  I/O  processing  would  proceed  on  a deniand/response  basis  at  an  iteration  rate 
determined  by  the  service  requirements  of  that  particular  sensor/actuator.  If  the  I/O  device  had 
interrupt  response  requirements,  the  application  program  would  have  an  I/O  interrupt  service 
module  incorporated  within  it  to  service  the  I/O.  The  logic  behind  this  scheme  of 
implementation  is  that  the  results  generated  by  the  applici  tion  program  servicing  such  LO  are 
dependent  upon  the  data  input/output  to  (from!  the  I/O  device.  If  such  interrupts  are  periodic 
and  predictable,  the  application  program  can  be  scheduled  periodically  to  service  the  I/O 
interrupts  when  they  occur.  I/O  devices  with  asynchronous  interrupts  can  be  serviced  in  the 
following  manner.  The  application  program  which  is  responsible  for  servicing  this  type  of  I/O 
would  be  scheduled  by  the  GEX.  at  system  startup.  A module  (routine)  of  this  application 
program  would  be  the  I/O  interrupt/device-turn-on-monitor  module,  and  would  be  sufficient  to 
service  I/O  interrupts  from  the  device.  A chain  of  events  could  then  be  based  on  the  device 
input.  For  example,  such  an  application  task  could  asynchronously  generate  output  data  for 
other  tasks  by  calling  the  LEX  and.  in  response,  receive  input  data.  The  entire  operation  can  be 
described  by  a lattice  (directed-graph)  structure.  The  PIT  which  is  used  by  the  LEX  to  monitor 
an  application  program’s  time  away  from  the  Executive  can  be  used  in  this  case  to  periodically 
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query  tlu*  status  ol  the  applications  program  which  is  constantly  monitoring  the  l'()  device  lor 
which  it  is  cognizant  tor  incoming  interrupts. 

I lie  other  area  which  required  close-  examination  was  the  processing  ol  messages  incoming 
over  the  data  buses.  The  area  ol  concern  was  to  maintain  the  integrity  of  incoming  data  in  an 
environment  where  data  could  and  would  be  generated  at  a taster  rate  than  at  which  it  is  used. 
The  analysis  ot  this  problem  suggested  the  following  solution.  An  application  program  which  uses 
data  at  a rate  slower  than  at  which  it  is  generated  by  some  other  task  can  use  the  latest  copy  of 
such  data,  provided  the  “latest"  copy  contained  a set  of  data  all  generated  at  the  same  time.  In 
other  words,  care  would  have  to  be  taken  to  give  to  an  application  program  a set  of  data  which 
was  complete  and  not  being  overwritten  at  the  time  control  was  passed  to  the  application 
program.  The  logic  for  implementing  this  safeguard  has  been  designed  into  the  DP  M Hxecutive 
software  and  is  described  in  detail  in  the  description  ol  the  bus  message  input  modules. 

An  area  that  was  analyzed  but  not  implemented  into  the  executive  code  was  the  capability 
to  re-request  data.  It  was  concluded  that  in  an  avionics  environment  where  most  all  subtunctions 
are  periodic,  the  elapsed  time  between  the  receipt  of  bad  data  and  the  next  time  this  data  will 
be  generated  being  based  on  the  iteration  period  ot  both  sending  and  recipient  tasks,  little  would 
be  gained  by  re-requesting  data.  However,  it  is  a valid  contention  that  the  Hxecutive  software  he 
able  to  support  re-requesting  of  data,  should  this  be  required.  The  Hxecutive  design  is  able  to 
support  this  requirement.  A sending  task  would  be  required  to  keep  a copy  of  the  data  generated 
by  it.  until  new  data  is  generated.  An  hxecutive  “task"  could  then  be  designed  that  would  be 
given  control  by  the  LHX  when  the  re-request  message  was  received.  This  hxecutive  “task"  could 
then  obtain  and  put  the  required  data  set  address  into  the  output  queue  and  preempt  processing 
in  the  Ph  to  the  extent  ot  enabling  an  asynchronous  output  transfer  ot  data. 

In  the  previous  discussion,  it  has  been  stated  that  the  Scheduler  module  ot  the  Global 
Hxecutive  schedules  time-dependent  subfunctions  in  the  DP  \1  system  when  it  is  time  for  them 
to  run.  and  other  predecessor  conditions  tsuch  as  the  activated  status  of  the  subfunction,  the 
past  completion  of  the  subf unction,  etc.)  have  been  satisfied.  It  was  also  stated  that  tasks  are 
scheduled  by  the  Local  hxecutive  only  v.heti  their  predecessor  requirements  are  satisfied.  The 
LhX  scheduling  function  does  not  have  a tune  dependency,  per  se.  This  executive  control 
approach  would  seem  to  work  well  in  an  avionics  environment  in  »vhich  all  subfunctions  have  a 
relative  time-to-run  relationship  among  them.  This  requires  that,  when  any  subfunction  is  active, 
it  shall  be  required  to  run  in  a tixed  time  slot  relative  to  the  tune  to  run  ol  some  othe- 
subfunction  in  the  system  whether  the  latter  subfunction  is  active  or  inactive.  The  above 
relationship  was  the  basis  for  the  design  ot  the  scheduling  algorithm  of  the  Gl  X.  The  Gl-.X 
scheduler  tries  to  schedule  a subtunction  when  if  is  tune  for  that  suhlunction  to  run.  Only  other 
predecessor  conditions  ol  tl. , subtunction  that  may  not  be  satisfied  at  this  tune  (e.g..  the 
subfunction  may  be  inactive)  pa-vent  the  GI.X  scheduler  front  sending  a "go"  message  to  the 
subtunction. 


■here  may  be.  in  an  avionics  software  environment  however,  certain  subfunctions  which 
,.'e  no  !.-•  ; relationship  whatever  with  any  other  subfunction.  Such  subfunctions  may  become 
. • i. use  of  the  occurrence  ot  a certain  event  and  become  inactive  when  that  event  is  past. 
A v^-dion  might  well  be  asked  whether  the  executive  software  control  system  as  described 
previously  will  be  able  to  handle  this  type  of  subfunction(s).  Note  that  LI  X scheduling  is 
entirely  predecessor-driven.  Suppose  that  a certain  subfunction  which  does  not  have  a need  to 
run  is  dormant,  also  suppose  that  this  subtunction  does  not  have  a representative  element  in  the 
GHX  scheduler's  time-ordered  list  and.  therefore,  cannot  be  time-scheduled  from  the  Gl  X.  Now. 
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an  event  occurs  in  the  DP/M  system  that  generates  a set  of  data  and  the  subfunction  that  has  a 
requirement  for  this  data  is  the  dormant  subfunction.  If  the  subfunction  is  not  collocated  with 
the  set  ol  data,  the  PI'  associated  with  the  data-generating  event  could  use  its  LEX  to  transfer 
the  data  over  the  Local  or  Global  communication  bus,  depending  on  the  connectivity  of  the 
sending  and  receiving  PEs  to  the  logically  addressed  PH  containing  the  dormant  subfunction.  The 
receipt  ol  this  data  would  then  generate  a message  complete  interrupt:  the  appropriate  LEX 
module  would  be  called,  which  would  provide  the  correlation  between  the  incoming  data  and  the 
dormant  subfunction,  and  decrement  the  subfunction's  predecessor  count.  Assuming  that  this 
count  goes  to  zero,  the  dormant  subfunction  becomes  active.  The  task  preamble  can  be 
structured  in  the  PE  so  that  such  subfunctions  are  self-sustaining.  In  other  words,  the 
subfunction  could  be  made  its  own  predecessor,  by  merely  indicating  appropriate  relationships  in 
the  preamble  tables.  The  preamble  tables  can  also  be  used  in  a similar  manner  to  structure 
"control"  tasks  around  the  basic  LEX  defined  in  this  specification  to  build  a relationship  among 
subfunctions  that  are  related  to  each  other  but  are  not  time-dependent.  PEs  having  such 
subfunctions  would  still  participate  in  bus  control  and  respond  to  GEX  control  messages. 
Subfunctions  could  talk  to  each  other  and  pass  messages  between  each  other,  the  OHly  difference 
being  they  receive  no  time-dependent  "go”  message  from  the  GEX  scheduler.  Monitor 
responsibility  for  all  subfunctions  in  this  subgroup  would  be  decentralized  from  the  GEX, 
possibly  to  one  of  the  PEs  in  the  subgroup. 

An  interesting  application  of  this  concept  would  be  the  activation  of  a dormant 
subfunction  in  a PE  when  an  infrequent  stimulus  arrives  from  the  sensor  for  which  it  is 
responsible.  As  discussed  in  the  above  paragraph,  a “control”  task  could  be  defined  in  that  PE 
which  would  be  activated  when  the  sensor  I/O  interrupt  occurred.  This  control  “task”  would 
subsequently  exit  to  the  LEX  and.  depending  upon  the  lattice  structure  defined  for  the 
subfunction,  a series  of  activities  could  be  initiated  as  a result  of  this  action. 

The  Executive  software,  as  designed  for  the  DP/M  system,  is  therefore  quite  flexible.  By 
its  very  nature  of  being  table-driven,  it  provides  separation  of  system  logic  and  application 
software  modules.  Not  only  can  modifications  and  additions  be  made  to  application  software 
modules,  but  the  capabilities  of  the  Executive  can  be  expanded  to  perform  a multitude  of 
functions  by  defining  “control”  tasks.  This  is  demonstrated  in  the  design  of  several  modules  of 
the  DP/M  GEX.  and  in  the  suggested  nature  of  various  possible  Executive  software 
configurations,  as  discussed  in  this  section. 

In  conclusion,  the  executive  design  is  flexible  enough  to  provide  for  modular  addition 
without  requiring  extensive  baseline  design  changes.  Just  as  in  the  case  of  relative  speed/ 
flexibility  tradeoffs  between  micro-programmed  and  hard-wired  computers,  a similar  analogy  can 
be  drawn  for  the  DP'M  baseline  executive  design.  The  indications  from  design  analysis/simulation 
have  shown  that  the  overhead  contributed  by  the  table-driven  Executive  should  be  minimal  and 
that  the  proposed  Executive  is  capable  of  meeting  the  real-time  requirements  of  the  DP/M 
system. 

I.  SIMULATION  MODEL  DEVELOPMENT 

Part  of  the  DP/M  executive  design  effort  was  the  development  of  simulation  models  of 
various  executive  routines  in  FORTRAN  ai  1 PE  assembly  languages.  Subsection  VII.D.I2  of  the 
DP/M  Functional  Simulation  section  described  the  event  models  that  were  incorporated  into  the 
System  Network  Simulator.  These  models  were  used  in  the  Process  Construction  case  study 
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described  in  Subsection  IX.I).  Additional  FORTRAN  models  were  developed  to  check  logic  used 
in  different  executive  routines. 

The  development  of  certain  LKX  and  GKX  assembly  language  routines  was  undertaken  to 
determine  approximate  timing  and  memory  requirements  for  different  executive  functions.  A 
summary  of  these  routines  and  their  respective  instruction  and  memory  requirements  is  found  in 
Table  33.  Timing  equations  such  as  the  one  described  in  Figure  1 53  were  formed  and  used  in  the 
execution-time  calculations  of  the  FORTRAN  System  Network  Simulator  models. 


TABLE  33.  ASSEMBLY  LANGUAGE  MODEL  DEVELOPMENT 


Number  of 

Number  of 

Instructions 

Memory  Words 

GI'X  SHIED 

GEX  Scheduler 

x5 

101 

RCLOCK 

Clock  Update  Task 

15 

lx 

OMESS 

Output  Message  Interpretor 

54 

72 

BISVt 

Bus  Interrupt  Service 

II 

l<> 

MSGXMTG 

Bus  Message  Transmitter 

>7 

37 

Ttl.P 

Task  Control  Entry  Point 

II 

15 

BSCODE 

Branch  Successor  Scanner 

X 

X 

GEX  DISP 

Scheduler  Service  Module 

XX 

100 

SSCODE 

Successor  Scanner  Module 

i: 

i: 

IMSGC'ODh 

Inpul  Message  Scanner  Nlbduk- 

71 

•X, 

DISPTODE. 

Dispatcher 

2X 

3X 

ACTDACT 

GEX  Activate  Deactivate  Monitor 

3: 

40 

(OMPSTS 

1.1. X Completion  Status  Monitor 

n 

13 

The  el  fort  associated  with  assembly  language  coding  of  key  executive  modules  provided  a 
good  insight  into  the  adequacy  of  the  DP  M instruction  set.  The  extended  short  format 
instructions  were  frequently  used  and  provided  good  savings  in  execution  times  and  storage 
space.  The  autoincrement  instruction  and  the  increment  and  branch  on  zero  instruction  together 
served  as  an  excellent  tool  in  the  efficient  scanning  ot  tables  whose  first  word  contained  the 
count  of  the  number  of  entries  m the  table.  Interestingly  enough,  most  of  the  executive  tables 
have  this  format  and  the  instructions  were  put  to  good  use  The  direct  indexed  feature  was  also 
very  useful  in  accessing  data  found  at  different  indexed  locations  oil  a common  base. 

Particularly  useful  instructions  that  were  identified  included  the  move  and  autoincrement, 
the  test.  set.  and  clear  bit.  and  the  push  and  pop  multiple  instructions.  File  move  and 
autoincrement  with  the  available  instruction  modifications  was  used  lor  memory -to-meinory  data 
transfers,  moving  the  contents  of  one  table  to  another,  initializing  tables,  etc.  The  bit 
instructions  can  be  used  for  testing,  clearing,  and  setting  Hags  These  instructions  help  conserve 
memory  space  and  execution  tunc,  since  Hags  could  be  compressed  in  with  data  words  and  an 
elaborate  logical  mask  and  set/ clear  operation  would  not  be  required.  The  push  and  pop  multiple 
instructions  provided  a quick  efficient  means  ot  saving,  restoring  registers  for  subroutine  and 
interrupt  processing. 
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where 

xf  — 0 if  subfunction  is  not  running  the  very  first  time  this  segment 

x:  = 0 if  subfunction  his  no  dependent  subfunction 

Xj  ■ 0 if  dependent  subfunction  is  not  in  time-ordered  list 

X4  = 0 if  time  ordering  is  not  required 

xs  - 0 if  scheduling  has  not  slipped 

n(  - number  of  dependent  subfunctions 

n:  = number  of  moves  required  to  time-order  subfunction  element 

Note:  The  execution  time  of  the  GEX  scheduler  is  dependent  upon  a number  of  parameters: 

(1)  Is  subfunction  being  scheduled  for  the  first  time  in  segment? 

(2)  Oo  any  dependent  subfunctions  exist? 

(3)  Is  the  dependent  subfunction  in  time-ordered  list7 
Ml  Total  number  of  dependent  subfunctions. 

(5)  Time-ordering  required? 

(6)  How  many  moves  to  time  order7 

(7)  Any  scheduling  slippage7 

Further  timing  information  is  found  in  the  DP/M  Executive  functional  specification. 


Figure  1 S3.  GEX  Scheduler  Timing  Equations 


J.  SYSTEM  INITIALIZATION  PROCEDURE 

System  initialization  was  considered  a part  of  the  investigation  into  types  ol  DP  M system 
operation.  It  was  important  to  consider  the  detailed  aspects  of  system  initialization  requirements 
during  the  system  component  design  to  ensure  that  the  initialization  procedure  is  supported  and 
facilitated  by  the  individual  functional  system  hardware  design.  The  following  paragraphs 
describe  one  suggested  method  of  providing  a cold-start  initialization  for  a variety  of  network 
configurations,  as  well  as  for  systems  that  have  variable  memory  mixes,  i.e.,  ROM  or  RAM  data 
and  program  memory,  etc.  Functionally,  the  initialization  procedure  allows  the  loading  of  the 
read/ write  memory  space  of  all  Pl-.s  in  a given  system  configuration  from  a mass  memory  unit 
(“program-loader"!  which  has  a direct  I/O  connection  to  the  Global  hxecutive  PF.  Each  PF  is 
provided  with  a minimal  amount  01  hard-wired  control  to  accomplish  the  system-initialization 
procedure. 


The  DP/M  s>\  stem  allow-*  data  inputs/outputs  locally  to  each  1*1-  over  individually  dedicated 
I/O  channels,  and  data  transfers  among  I’l  s over  either  the  (ilobal  or  Local  buses,  depending 
upon  the  topological  connectivity  of  the  system  The  later  scheme  ot  data  input  is  implemented 
by  a hardware  sottware  procedure  ol  input  message  recognition  and  selection  using  the  Message 
Identity  Associative  Match  Map  (MIAMM)  described  in  Section  III  ol  this  report.  This  same 
scheme  of  data  input  is  used  to  load  programs  into  eacn  PI  at  system  initialization.  However, 
since  the  semiconductor  memory  of  each  PI  can  come  up  in  an  indeterminate  state  at  power  up. 
a means  must  be  provided  to  mitiah/e  the  MIAMM  region  ol  memory  to  allow  proper  message 
recognition  selection  procedure  in  response  to  sy  stem-unti.di/at  ion -control  messages.  A candidate 
method  is  described  in  the  following  paragraphs 

1 . Initial  State  of  the  System 

When  power  is  applied  to  the  DP  M system.  a clear  reset  signal  provided  to  each  PL  by  the 
individual  DP  M power  supplies  initiates  hardware-controlled  vectoring  of  the  PL.  to  a ROM 
containing  the  PI  initialization  bootstrap  program  I he  clear  reset  signal  also  brings  the  entire 
DP  M system  into  a known  stale.  In  this  known  state,  all  programmable  (enable, 'disable)  bus 
interlace  control  registers  and  interrupts  come  up  disabled.  I he  partial  state  ot  the  system  as 
pertinent  to  this  discussion  is:  all  PI  - have 

(ilobal  bus*  interlace  input  data  sections  enabled 

(ilobal  bus  interface  output  data  sections  disabled 

(ilobal  bus  interlace  bus  position  and  length  registers  in  an  indeterminate  state 
Bus  qttiescetu e and  dominance  detection  disabled. 

2.  ROM  Bootstrap  Program 

At  power  up.  each  PI  is  vectored  to  and  begins  executing  instructions  from  a ROM 
bootstrap  program.  The  PI  as-emblv  language  code  for  this  bootstrap  is  shown  in  Figure  154.  A 
bit  pattern  is  inserted  as  an  input  message  match  mechanism  into  the  MIAMM  in  each  PL.  This 
will  now  enable  each  PL.  to  recognize  and  input  the  software  boots»rap  program  and  diagnostics 
that  are  subsequently  addressed  to  all  PI  s.  The  ROM  program  in  all  PI  s then 

( 1 ) Arms  the  "input  message  received " interrupt 

(2)  Initializes  this  interrupt  s trap  location  to  the  RAM  address  into  which  the  software 
bootstrap  program  is  to  be  loaded 

(3)  Initializes  the  autonomous  I/O  data  transfer  channel  (ATO  trap  location  to  the 
hcginnmg  execution  address  ot  the  program  which  is  to  be  loaded  from  mass 
memory  into  the  (»FX  PL 

(41  Activates  the  ATC  for  mass  memory  input 

(5»  Finally  enters  an  "idle'*  state. 

Only  one  PL.,  the  GLX  PL.  which  is  connected  to  the  mass  memory,  will  receive  the  system 
initialization  program  trom  the  mass  memory.  When  data  transfer  is  complete,  the  ATC*  interrupt 
causes  a trap  to  its  reserved  memory  location.  This  location,  which  was  previously  initialized  to 
the  starting  address  of  the  start-up  program  (just  loaded  from  mass  memory)  vectors  the  PH  to 
this  starting  address.  The  (if*  X PI.  is  now  under  program  control  and  system  program  loading  can 
begin. 
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4 Software  liooislrap  IVouram  load 

lliv  Ills!  iceord  lead  li>  llie  <d  \ Cl  Ii.-m  mass  niemoi.)  contains  flic  software  lioolsirap 
propiam  (SHIM,  flic  < ,1  X I’l  broadcasts  Hie  SHI’  to  all  I’l  s.  The  input  message  cumplclion 
uileM'iipl  vectors  llie  1*1  > io  Ilk  halt  "I  (lie  SUP  (the  Cl  .isseiuhly  language  code  lor  I lie  SHI’  is 
shown  ill  figure  1 55  I.  f he  SUP  escciiles  an  lOaclivitc  which  reads  a hardware-assumed  iilciitiiy 
<ll)l  that  has  Ivon  iimoiiclv  assigned  to  each  Cl  . This  II)  is  (ranslalcd  inlo  a Ivil  pallern  and 
inserted  into  (lie  MIAMM.  thereby  allowing  llie  Cl  lo  identify  and  load-in  system  programs  that 
are  addressed  lumpfc'ly  lo  u.  II  (lie  KOM  l< AM  mixes  ol  the  various  PI  s in  a given  configuration 
are  dillerenl.  (Ills  software  hoolslrap  piograi n will  lie  nniipie  lo  each  I'l  and  shall  contain  the 
memory  address  inlo  which  system  progums  I'oi  cadi  Cl  miisi  he  loaded.  llie  SIIP  initializes  the 
MIAMM  and  the  Meinoiy  Bullci  Veelor  Space  lor  system  ploy i am  loads  inlo  each  PC.  so  that 
proper  routing  ol  incoming  messages  is  allowed.  When  llie  SHi'  has  completed,  it  idles,  awaiting 
transmission  ol  actual  system  applications  programs  loi  (lie  ( » I •. X Cl  . * 

4.  System  Program  Loads 

I he  next  progiam  that  is  loadetl  !u>m  mass  memoi)  into  each  PC  is  a PI  diagnostic 
pioyram.  * he  fjfX  PI  keeps  a copy  <>l  the  piogiam  in  its  memory  and  broadcasts  a copy  load 
memher  Pis  ol  llie  l)P/M  * onligiii.iltou  I a>  h I'l  then  eseeules  llie  diagnostic'  progiam  and 
builds  a stains  map.  Ilus  status  map  will  be  output  to  the  (•!  X when  the  (>l  X PI  interrogates 
individual  PI  s at  the  time  ol  loading  that  PCs  piogi.mi.  Alter  the  (ilX  finishes  its  diagnostic 
lest,  it  eseeules  a timeout  to  give  siitlnienl  time  lo  the  other  Pis  to  complete  llicit  lest.  The 
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Figure  1 55.  Software  Bootstrap  Procedure  Code 


GHX  then  requests  the  first  program  from  the  mass  memory.  This  program  has  a message  header 
so  that  it  is  appropriately  recogni/ed  by  the  cognizant  PH.  When  the  program  transmission  is 
complete,  the  GHX  PH  waits  for  the  PH  that  was  just  loaded  to  return  status.  This  status 
includes  the  results  of  the  diagnostic  test  that  was  previously  run  and  whether  or  not  the 
program  was  completed  by  the  PH.  without  any  error.  After  the  PH  has  sent  its  status  to  the 
GHX.  it  disables  it  output  section,  loads  its  bus  position  and  length  registers  to  appropriate 
values  for  subsequent  system  synchronization  (as  directed  in  previous  bus  message 
communications*,  and  goes  idle.  The  GHX  now  requests  the  next  program  from  the  mass 
memory  and  routes  it  appropriately.  This  same  procedure  is  repeated  until  all  PHs  in  the  DP/M 
system  have  been  loaded  with  their  respective  applications  program(s>  and  data  basefs). 

5.  System  Synchronization 

After  the  programs  have  been  successfully  loaded  into  each  PH.  a “system  synchronization 
pending"'  message  is  broadcast  to  all  PI  s.  This  message  signals  all  PHs  to  enable  their  bus  activity 
watch-dog  timers  and  their  output  interlaces.  The  state  of  the  bus  position  and  length  registers 
will  have  been  previously  set  up  bv  software,  such  that  the  GHX  will  output  the  first  sync  pulse 
(message  sync  signall  on  the  Global  bus.  As  this  signal  propagates  to  all  PHs.  the  system  will  be 
pulled  into  synchronization  as  each  successive  Pi  's  bus  position  counter  gets  decremented  to 
zero  and  reset  to  the  bus  length.  A similar  scher.e  synchronizes  all  Local  buses  in  the  system 
with  one  PH  in  each  Affinity  Group  given  the  responsibility  of  making  Local  bus  synchron- 
ization. At  this  stage,  the  system  is  in  a fully  initialized  state  and  is  ready  to  begin  actual  mission 
processing. 
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K.  SUMMARY  OF  DP/M  EXECUTIVE  STRUCTURE 


Reiterating  statements  nude  earlier,  the  goal  ol  the  1)1*  M I xccutive  structure  design  was 
to  investigate  the  requirements  necessary  for  establishing  supervisory  control  ami  data  transters 
between  avionic  suhtumtion  tasks  in  a network  ol  1*1  s.  The  directed-graph  predecessor-successor 
relationships  established  a convenient  way  ol  rept  event  mg  application  tasks  lor  processing  by 
executive  routines  The  use  ot  sets  ol  predecessor  conditions  (e.g.,  inter-l’l  Inis  messages)  form 
the  foundation  toi  all  scheduling  activities.  The  incorporation  of  this  scheduling  data  into  a 
common  table  structure  resulted  in  the  specification  of  a simple  yet  adequate  control  scheme 
that  is  adaptable  to  multiple-Pl  conliguratioiis.  I he  modules  identit ic  I lor  the  1.1  X provide  the 
necessary  control  and  message  processing  tor  tasks  within  a 1*1  . Hie  I ' \ design  is  independent 
ol  overall  system  control  schemes  and  can  support  either  the  tightly  coupled  or  loosely  coupled 
philosophy  ol  operation  I he  use  ot  predecessor-successor  conditions  can  be  used  tor  directed 
graphs  ot  functions,  subtuiictions.  and  task  relationships.  This  convention  otters  a convenient 
means  ot  representing  mode  changes,  error  responses,  task  scheduling,  and  subfunction  scheduling 
in  an  avionics  environment.  The  (il  \ design  used  these  basic  features  ottered  by  the  l.».X 
routines  and  also  provided  a basic  set  ot  total  system  control  (unctions.  These  basic  system 
operations  included  time  scheduling  ol  suhlunc lions,  activating  and  deactivating  subfunctions, 
and  multiple'  initiation  ot  subtuiictions  based  upon  a mission  mode  change.  The  detailed  design 
ot  these  total  system  control  (unctions  is  dependent  upon  an  exact  set  of  subfunctions,  sensors, 
and  a detailed  specification  of  system  operating  modes.  I lie  design  specification  ol  these  global 
(unctions  is  based  upon  likely  types  ol  operation  and  is  expected  to  evolve  as  DP  M is  applied  to 
specific  mission-processing  scenarios. 
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SECTION  IX 

PROCESS  CONSTRUCTION  STUDY 

A.  INTRODUCTION 

This  section  investigates  the  problems  associated  with  the  construction  of  real-time 
processes  for  DP  M networks.  The  main  objective  of  this  work  is  to  formulate  the  requirements 
for  a l)P  M process  constructor  and  to  outline  its  high-level  design,  both  of  which  are  presented 
in  Subsection  IX.C,  Summary  of  Requirements.  The  formulation  of  requirements  and  the 
development  of  an  approach  for  DP/M  process  construction  required  investigation  of  secondary 
problems  and  finding  answers  to  numerous  questions  related  to  process  construction.  For 
example,  the  managerial  aspects  of  the  development  of  process  construction  capabilities  had  to 
be  examined  and  various  optimization  algorithms  had  to  be  investigated.  A discussion  of  these 
problems  appears  in  Subsection  IX.1J.  Problem  Analysis,  in  addition.  : n actual  process 
construction  exercise  was  carried  out.  during  which  a process  model  for  a partial  "Close  Support 
Mission"  was  constructed  by  means  of  computerized  tools  developed  in  the  course  of  the  work 
reported  here.  The  objectives  of  this  exercise  were  not  only  to  demonstrate  the  current  Texas 
Instruments  approach  to  and  capabilities  in  DP'M  process  construction  but  also  to  acquire  a 
better  intuitive  understanding-  of  the  related  problems.  The  results  of  this  exercise  are  described 
in  Subsection  IX.D.  Process  Construction  Case  Study.  Possible  improvements  in  the  process 
construction  procedure  and  a suggested  future  course  of  action  are  summarized  in 
Subsection  IX.H.  Recommended  Future  Activity  in  DP/M  Process  Construction. 

1 . Process  Construction  Problem  Statement 

The  development  of  computer-based  teal-time  systems  is  a challenging  task.  First,  the 
system  to  be  created  must  satisfy  the  timing  constraints  stated  in  the  design  requirements.  Its 
programs  must  interplay  in  a temporal  order  such  that  the  logical  system  constraints  remain 
satisfied.  Furthermore,  it  must  accomplish  its  mission  well,  such  as  controlling  a plant, 
performing  on-line  services  for  some  external  process,  or  controlling  a set  of  sensors  and 
performing  avionic  functions.  Finally.:  the  system  must  be  reliable  and  dependable,  because  the 
cost  of  failure  may  be  catastrophic. 

Difficulties  in  the  development  of  software  for  a real-time  computer  system  typically  start 
to  abound  in  that  phase  of  work  during  winch  individual  modules  must  be  combined  into  a 
working  system  and  when  testing  of  the  timing  and  logical  constraints  begins.  This  phase  is 
usually  called  system  integration.  Concurrencies  in  a typical  real-time  system  contribute  to  the 
conceptual  difficulties  that  its  designer  faces  and  make  the  system  integration  job  more  difficult. 

Tile  situation  becomes  even  more  critical  if  the  system  structure  is  high  parallel,  as  in  the  case  of 
DP  M computer  networks. 

During  the  last  few  years,  great  progress  has  been  made  in  software  engineering,  structured 
programming,  top-down  software  development  concepts,  program  validation  theory  and 
techniques,  and  modeling  and  simulation  techniques  for  software  design  purposes:  the  currently  j 

active  research  in  programming  languages  (as  well  as  the  appearance  of  languages  such  as  j 

PASCAL)  is  a noteworthy  recent  development.  However,  most  of  these  developments  have 
overlooked  that  phase  of  real-time  software  development  which  is  concerned  with  the  ] 

construction  of  a Ira  me  work  lor  software  to  run  in  real  time  and  to  satisfy  all  its  constraints.  ! 


Preceding  me  Mink 
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(icncr.ilion  dI  Midi  .1  tr.imework  is  known  among  i lie  practitioners  >1'  teal-tune  computer 
s\ stems  un  "process  construction."  (In  the  piescnt  omn'M.  the  term  "process"  moans  tho 
real-time  soltwuro.  ineliul me  t he  applications  us  well  us  system  proaiams.  uml  all  the  supporting 
siatu  huso  needed  to  make  tho  soltwuro  run  properly  m real  tnno. I There  is  no  umvorsally 
icooptoil  lecipe  stating  who'  activities  tho  piocoss  oonstiuotion  should  precisely  cover,  this  dilleis 
'rom  ono  ouso  »o  another.  (Generation  of  the  progium  loading  and  real-time  control  data  is  often 
considered  as  a minimum,  hut  main  other  aspects  of  software  development  and  optimization 
Jot n i ties  nay  he  viewed  as  being  process  construction  activities  l or  example,  optimal  structures 
for  real-time  programs  max  lie  generated  in  order  to  minimi/o  the  bus  trail ic  between  the 
processor  ot  a multi-computer  svstem.  or  the  memory  paging  in  real-time,  or  the  amount  (cost) 
ot  the  rapmed  hardware,  etc  furthermore,  a certain  amount  ot  p ocess  validation  can  he  done 
ul  process  construction  time.  It  the  validation  ot  assertions  about  the  sot t ware  correctness  (or 
the  process  of  making  the  sot t ware  reliable)  is  viewed  as  a multi-stage  filter  which  startsat  the 
time  the  piogrum  is  written  by  the  programmer  and  continues  through  the  actual  held  tests  of 
the  delivered  program,  then  process  construction  may  constitute  one  stage  of  this  filter  l or 
example,  certain  assertions  about  the  cortectness  ot  process  structure  (i.e..  whether  the  structure 
satisfies  the  tcquired  structural  constraints,  such  as  the  existence  ot  a single  entry  point  for  each 
program,  etc  i can  be  validated  at  process  construction  time. 

Another  wav  ot  looking  at  process  construction  is  that  it  tries  to  match  software  to 
hardware  or  vice  versa.  Individual  components  ot  the  real-time  settware  are  produced  and  tested 
by  programmers,  process  construction  tools  and  procedures  are  used  then  to  combine  these  into 
larger  units,  to  assign  computer  res  imes  to  each  unit,  and  to  establish  communication  links 
between  programs.  In  nonreal-time  computing,  the  user’s  interlace  mechanisms  with  the  system, 
mainly  occurring  through  a tob  control  or  terminal  language  and  the  linking  loader.,  are  the 
non i "jl-time  counterpart  ot  process  construction  They  try  to  provide  the  user's  program, 
possible  written  in  a relatively  computer-independent  wav.  with  the  hardware  and  sottware 
resources  needed  to  execute  the  program 

During  the  last  tew  years,  various  process  construction  techniques  have  been  successfully 
used  in  several  leal-tune  sottware  developments.  Presently,  the  construction  ot  processes  for 
conventional  computer  architectures,  such  as  multi  processor  or  multi-computer  systems,  is  fairly 
well  understood.  \s  new  types  ot  computer  architectures,  such  .o  microprocessor  networks,  .ue 
introduced  and  become  economically  attractive  lor  real-time  computing,  the  process  construction 
tunciions  tor  them  must  be  newly  investigated  and  established.  I or  example,  a microprocessor 
network  architecture,  in  which  microprocessors  teach  with  its  own  mvmoiy  i are  interconnected 
through  a bus.  otters  many  challenging  problems  to  the  designer  ol  the  process  construction 
system,  mainly  because  an  individual  Processing  I lenient  (PI  ) m such  a network  is  likely  to  have 
a very  limited  capacity,  but  the  overall  network  geometry  may  be  complex.  I oi  example,  a 
program  in  the  proce.s  may  easily  exceed  the  processing  capacity  til  any  Processing  I lenient  in 
the  network  m such  a case  I urthermore.  one  ot  the  (unctions  of  process  construction  is  to 
decompose  the  violating  program  into  several  components,  cadi  satisfying  the  timing  constraints 
and.  accordingly,  to  restructure  the  process.  The  way  m which  the  Pis  are  assigned  to  process 
components  may  affect  not  only  the  teal-tune  performance  ot  tin-  system,  the  complexity  of  the 
real-time  performance  of  the  system,  or  the  complexity  ot  the  executive,  but  also  the  amount  of 
needed  hardware  and  therefore,  its  cost,  as  several  hardware  configurations  of  different 
complexities  may  be  feasible. 


Oven  it*  w 


The  objectives  of  this  section  are  to: 

Analyze  the  problems  associated  with  the  development  of  process  construction 
capabilities  for  a DP  M computer  network 

Summarize  the  functional  capability  and  system  design  requirements  for  a first 
iteration  DP/M  process  construction  system. 

Die  problem  analysis  portion  of  this  section  (i.e..  Subsection  IX. B>  discusses  two  aspects 
ot  the  process  construction  capability  development,  the  functional  aspect  and  the  system  aspect. 
I'he  first  is  concerned  with  the  transtormations  and  algorithms  needed  in  DP/M  process 
construction.  Hie  second  aspect  deals  with  the  system  problems  of  piocess  constructor 
development,  or  with  the  process  constructor  as  a system  which  links  both  the  process  designer 
and  a computer  into  a loop.  In  the  analysis  of  system  problems,  answers  are  sought  to  questions 
about' 

I'he  scope,  or  extent,  of  process  construction  functional  capabilities 

Tiie  appropriate  level  of  automation  for  DP/M  process  construction 

What  is  the  right  approach  tor  developing  the  process  constructor,  i.e.,  whether  to 
d .elop  a full-capability  process  construction  system  at  once  or  to  build  it  up 
gradually  in  several  incremental  steps. 

The  problem  analysis  portion  ot  Subsection  1X.B  describes  the  development  methodology 
on  which  DP  M process  construction  is  to  be  based.  To  lay  a foundation  for  disc  ission  of 
process  construction.  Subsection  1X.B  starts  with  a review  of  the  assumptions  about  the  DP/M 
hardware  and  software  which  are  relevant  to  process  construction.  The  objectives  of  the 
functional  capability  analysis  are  < . , to  characterize  the  algorithms/procedures  that  come  up  in 
DP  M process  construction  and  (2 Mo  identify  the  key  algorithms/procedures  and  to  describe 
them  in  detail. 

As  noted  earlier.  Subsection  IX.C  summarizes  the  functional  capability  and  system  design 
requirements  for  a tirst-generation  process  construction  system,  called  Basic  Process  Constructor. 
These  requirements  are  stated  in  sufficient  detail  also  to  serve  as  a high-level  system  design 
speed ication.  The  heart  of  the  requirements  is  the  description  of  the  process  construction 
procedure  to  be  used  in  the  Basic  Process  Constructor.  This  procedure  is  to  be  implemented  as  a 
system  of  computer  programs  which  communicate  among  themselves  through  shared  data  sets. 
The  main  inputs  to  this  procedure  are  ill  the  computer-independent  design  of  the  process  and 
(2)  a model  of  a DP  M Processing  Piemen!.  The  outputs  of  the  procedure  define  the  mapping  of 
the  computer-independent  process  model  into  a specific  hardware  configuration.  Determination 
ot  that  configuration  is  a function  of  the  process  construction  procedure.  Furthermore,  this 
procedure  produces  ( I > process  documentation.  (2Mhe  control  data  which  is  needed  to  simulate 
the  process  or  to  run  it  in  real  tune,  and  (31  the  evaluation  data  addressed  to  the  piocess 
designer,  which  is  to  inform  him  about  the  expected  real-time  load  distribution  in  a DP/M 
network  Subsection  IX.D  describes  a process  construction  use  study  which  was  carried  out  by 
means  of  the  computerized  tools  developed  in  the  course  of  the  work  described  here.  The  last 
subsection.  IX.l . presents  a critical  evaluation  of  process  construction  investigations  and  suggests 
a future  course  of  action. 


B.  PROBLEM  ANALYSIS 


1 . Basic  Concepts  and  Definitions 

flic  objective  ol  Hie  present  subsection  is  to  summari/c  in  one  place  the  concepts  ami 
terminology  used  throughout  the  discussion  ot  process  construction.  For  that  purpose,  real-time 
processes  are  discussed  briefly,  then  the  construction  ot  such  processes  is  detmed.  and.  finally  .- 
basic  assumptions  made  about  the  soil  ware  and  hardware  for  which  real-time  processes  arc  to  be 
constructed  are  summari/ed. 

Uful-tinu 1 is  a i eal-t line  sot t ware  data  system  which  consists  ol  the  following  maior 

components: 

tl  i Real-time  exccutivetsi.  including  an  I O traffic  control  subsystem 

(2)  Applications  tie.  mission-oriented  or  tactical)  programs,  which  are  represented  by 
the  software  dedicated  to  perform  various  avionics  functions,  such  as  navigation, 
(light  control,  etc. 

(3)  A start-up  subsystem  for  initializing  the  real-time  operations  mission  of  the  entire 
DP  M system 

(4!  A real-time  data  base,  consisting  of 

(ai  Directories,  data  set  descriptors,  and  other  data  whose  primary  function  is  to 
facilitate  management  of  the  data  classes  listed  under  <h>  and  (c>  below 

tb)  Executive  control  tables  (to  be  used  by  the  real-time  executives) 

le)  Mission  support  data  (to  be  used  by  applications  programs) 

(5)  A real-time  pertoiinance  and  data  collection  monitor 

Items  (3)  and  (5)  listed  above  are  not  considered  to  be  vital  during  the  initial  phase  ol  process 
construction  research  and  development:  hence,  they  will  be  benignly  neglected  here. 

/Voicvv  uMUntitiun  is  a iionrcal-time  procedure  for  integrating  the  individual  components 
of  a process,  identified  in  the  preceding  paragraph,  into  a system  which  will  work  in  real  time 
and  which,  m particular,  will  satisfy  the  required  real-time  and  hardware  constraints.  In  the  case 
of  DP  M.  process  construction  includes  the  following  activities; 

(I)  Aualy  sis  ot  the  real-time  behavioi  ot  individual  software  modules  with  regard  to 

<a)  Processor  and  memory  loading,  including  satisfaction  of  real-time  constraints. 
tb»  Communication  with  other  software  modules  and  with  the  outside  world. 

1 2 1 Allocation  ot  appropriate  hardware  resources  to  process  components  (groups  of 
programs)  and  the  "first-cut''  determination  of  hardware  configuration  by  finding 
the  needed  number  of  DP  M Processing  Moments  (this  first  determination  of 
hardware  configuration  does  not  divide  the  Processing  Elements  into  Affinity 
(iroupsi. 

(3)  (ieneration  ot  the  control  framework  needed  to  run  the  process  in  real  time  by 
producing  the  control  portions  ot  the  real-time  data  base  and  by  linking 'loading  the 
programs  and  the  real-time  data  base. 


llic  term  "process  decomposition  analysis"  will  he  used  to  refer  to  the  activities 
eiuompassed  In  item  ( I l above,  flu*  term  is  descriptive.  for  the  main  function  of  the  process 
decomposition  analysis  is  to  determine  whetliei  a given  decomposition  of  tile  process  into 
components  will  meet  hardware  and  real-time  constraints.  The  activities  cohered  hy  item  12)  ute 
best  described  In  the  temis  "process  synthesis*'  01  “process  integrat'u  for  at  this  stage 
constituent  process  programs  are  combined  into  groups  and  mapped  into,  or  assigned.  Processing 
Hements.  Ihe  activities  belonging  to  the  third  group  are  reminis.vnt  of  tin*  conventional 
program  linking  and  loading.  Hence,  this  stage  ol  process  construction  often  will  be  referred  to 
as  the  process  linking  loading,  although  actu  illy  it  covers  much  more  than  the  conventional 
linking  and  loading.  For  example,  various  types  ot  control  tables  lor  mterprogram  communica- 
tion and  executive  control,  normally  not  considered  in  *'»e  conventional  program  linking,  are 
generated  during  the  third  stage  of  process  construction 

in  the  investigation  ot  problems  associated  with  the  establishment  of  process  construction 
capabilities  for  DP  M.  two  problem  are.i  become  • specially  evident.  The  first  one  addresses  the 
basic  question  about  what  prec.sely  should  be  done  or  is  needed  to  construct  DP  M processes 
fi.e..  w !:.it  functions  algorithms  are  needed  in  DP  M process  construction I.  The  other  is 
concerned  with  the  tools  that  shoulu  be  developed  to  facilitate  process  construction,  as 
determined  by  the  answers  obtained  from  solving  the  first  problem. 

I lie  required  process  construction  tools  collectively  are  referred  to  as  a /«wnv 
must  rut  tor.  One  ol  the  object :ves  of  this  section  is  to  investigate  the  requirements  for  and  to 
specify  the  design  for  the  initial  version  ol  such  a system,  to  be  called  Hast c Process  Constructor. 
Brictly.  Basic  Process  Constructor  is  to  be  a computerized  system  of  computer  programs  which 
intercommunicate  among  thcmsclvc*  through  shared  data  files,  accept  inputs  from  the  process 
designer,  inform  him  of  the  intermediate  results  while  the  process  construction  procedure  is 
processing,  and,  finally,  generate  tin  linking  loading  and  the  real-time  control  data.  Thus, 
process  construction  as  viewed  here,  is  a multi-step  iterative  procedure,  including  the  designer 
and  a computer  in  the  loop. 

flic  extent  and  the  nature  of  the  functions  which  a process  constructor  is  capable  of 
performing  will  be  referred  to  as  the  Jmn  ttoinil  mo/ic  oj  prmvs'  tonsirut  tion.  For  example,  a 
typical  linking-loader,  when  used  through  a standard  job  control  language,  represents  a process 
constructor  whose  functional  scope  is  very  limited:  on  the  other  extreme  a highly  automated 
system,  incorporating  numerous  analysis  and  optimization  algorithms,  facilitates  the  development 
and  hnking-loadmg  ol  soil  ware  systems.  Thus,  the  designer  ot  a process  constructor  faces  the 
ditlicult  task  of  determining  the  appropriate  functional  scope  of  the  system  to  he  designed. 
Clearly,  the  functional  scope  of  a process  constructor  is  determined  not  only  by  functional 
requirements  and  by  technological  limitations  but  also  by  economics.  The  problem  of  selecting  a 
suitable  scope  for  the  DP  M process  constructors  is  discussed  in  Subsection  IX.B.4. 

Another  set  ot  decisions  which  the  designer  of  a process  constructor  confronts  is  how 
much  the  process  constructor  should  be  automated  or  computerized.  It  is  not  only  a problem  of 
economics  but  dso  that  ot  deciding  which  tasks  can  be  better  or  more  efficiently  performed  bv 
man  than  by  a computer,  or  vie*  versa.  The  problem  of  selecting  an  appropriate  level  of 
automation  for  DP  M process  constructors  is  discussed  in  Subsection  IX.B.3. 

The  next  problem,  which  to  a great  extent  is  of  management-decision  nature,  is  to  come 
up  with  a sensible  plan  for  developing  process  construction  tools  and  capabilities.  A specific 
approach  for  developing  them  for  DP  M process  construction  is  outlined  in  Subsection  IX. B. 4. 


Tins  plan  is  based  on,  a multistage  development  ot  incremently  more  powerful  process 
constructors,  the  first  one  (already  teferred  to  as  the  Basic  Process  Constructor!  being  a subset  of 
all  the  others. 

Before  designing  a process  construction  system,  a set  of  basic  assumptions  on  which  the 
development  of  the  real-time  process  software  is  to  be  based  must  be  generated.  Software 
engineers  have  several  options  in  that  respect.  For  example,  they  may  choose  the  traditional 
software  development  approach  based  on  bottom-to-top  integration  or  they  may  select  the 
top-down  approach  which  would  use  structured  programming,  hither  approach  may  require  a 
different  type  of  process  constructor.  Consequently,  it  was  necessary  to  analyze  and  describe  the 
methodology  on  which  the  development  of  the  DP/'M  real-time  software  is  to  be  based:  this  has 
been  done  in  Subsection  IX.B.2. 

a Assumptions  About  DP/M  Hardware  and  Software 

Next,  a few  basic  assumptions,  relevant  to  process  construction,  about  the  DP/M  hardware 
and  software  shall  be  reviewed.  Since  these  assumptions  are  summarized  in  Section  IX.C.l  (i.e.. 
at  the  beginning  of  the  discussion  of  the  DP/M  process  construction  requirements),  they  will  not 
be  restated  here,  although  they  should  be  read  at  this  point.  Here,  the  discussion  will  be  limited 
to  stating  several  observations  which  should  complement  the  summary  of  assumptions  in 
Section  IX.C.l: 

1 1 ) One  remarkable  feature  which  permeates  throughout  the  design  of  DP/M  is  the 
two-level  hierarchy,  which  manifests  itself  in  hardware  and  soft  -are  design.  In 
hardware,  the  two-level  hierarchy  occurs  through  the  organization  of  the  micro- 
processor network  into  clusters  of  Processing  Elements,  called  Affinity  Groups,  and 
through  the  Global  and  Local  bus  systems.  In  software,  the  two-level  hierarchy 
occurs  through  it  organization  into  programs  (along  the  natural  boundaries  of 
avionics  and  other  mission-related  functions)  and  of  each  program  into  smaller 
functional  segments,  called  tasks.  It  also  occurs  in  the  design  of  the  current  real-time 
operating  system,  through  a two-level  control  system  consisting  of  a Global  and  a 
Local  Executive.  Consequently,  this  two-level  hierarchical  approach  also  shows  itself 
in  process  construction.  On  the  lower  level,  each  process  program  is  analyzed  as  to 
whether  it  can  be  accommodated  in  a single  Processing  Element  without  exceeding 
‘he  hardware  and  real-time  constraints.  On  the  higher  level,  programs  are  grouped 
into  clusters  and  mapped  into  individual  Processing  Elements  (or,  if  viewed  from  a 
different  angle.  Processing  Elements  are  assigned  to  such  program  clusters)  in  a way 
which  leads  to  minimization  of  the  bus  traffic  and.  thus,  the  minimization  of 
hardware. 

(2i  In  Subsection  IX.C.l.  practically  no  assumptions  about  the  real-time  Executive  are 
made,  for  it  is  expected  that  the  design  of  ti.is  system  will  further  evolve  and  change 
in  time.  For  this  reason,  the  phase  of  process  construction  which  most  closely 
interfaces  with  and  depends  on  the  Executive  design  (i.e..  generation  of  control 
tables  and  program  linking)  could  be  inves'igated  and  discussed  only  in  functionally 
generic  terms.  For  example,  it  would  have  made  littie  sense  to  specify  now  in  great 
detail  various  Executive  and  I/O  Control  tables  and  buffers  if  their  designs  will 
almost  certainly  change.  Furthermore,  it  is  presently  thought  that  this  la^t  phase  ol 
process  construction  is  straight  forward  m nature  because  it  consists  of  simple 
bookkeeping  and  data  processing  tasks. 


<.H  finally.  tin*  choice  ot  the  programming  language  lor  coiling  the  process  software 
great!)  altects  the  initial  phase  o!  process  construction,  i.e.,  that  phase  which  is 
inainl)  concerneil  with  ohtaimng  and  properly  organizing  all  needed  information 
about  the  process  to  he  constructed.  'I he  importance  ol  the  programming  language 
comes  not  only  through  the  language  constructors,  such  as  those  implementing  the 
process  inter-module  and  esternal  communications  or  the  storage  management  lor 
variables  used  In  a program,  hut  also  through  the  auxiliary  mtormution  about  the 
pioiess  structure  that  can  he  produced  as  a hy-prodiut  ot  compilation  It  is  widely 
believed  that  the  ultimate  success  of  microprocessor  networks  depends  on  the 
emergence  of  suitable  programming  languages  and  compilers.  Iloweiet.  m the  study 
being  described  here,  only  vers  minimal  assumptions  about  the  programming 
language  were  postulated.  The  whole  issue  of  programming  languages  could  he 
avoided  at  the  present  time  by  choosing  a multi-step  approach  tor  developing 
process  construction  capabilities:  the  first  piocess  construction  which  is  to  be 
produced  m this  development  cycle  and  which  is  specified  in  this  ic,n«rt  only 
assumes  the  availability  of  a conventional  higher  level  programming  language  such  as 
FORTRAN.  This  naturally  has  been  done  at  the  cost  of  not  being  able  to  automate 
the  initial  phase  ot  the  process  construction  procedure  to  the  extent  it  would  have 
been  possible  had  a special  higher  level  programming  language  and  a special  compiler 
been  assumed. 

As  a rc  .ult  ol  what  has  been  said  above  in  remarks  (2)  and  Oh  the  attention  during  the 
process  construction  investigations  discussed  presently  was  largely  focused  upon  the  process 
analysis-decomposition  and  the  process  synthesis  and  resource  allocation  problems.  The  other 
two  problems  I interfacing  with  a special  programming  language  and  its  compiler  and  interfacing 
with  the  real-time  operating  system)  were  identified  as  being  important  but.  because  of  the  time 
limitations,  were  given  reduced  emphasis 

b Prtteess  Representations 

One  of  the  first  stops  in  process  construction  is  generation  of  distracted  process 
representations  which  would  contain  all  subsequent Iv  needed  information  and  be  convenient  to 
work  with.  Tins  information  can  roughly  be  divided  into  that  describing  the  process  structure 
ami  that  defining  the  physical  attributes  ol  process  components. 

file  first  type  of  information  describes  various  aspects  ol  process  dynamics,  at  least  two  of 
which  arc  ol  interest  to  the  process  designer.  I he  lirsi  aspect  delines  the  information  flow 
through  the  process  during  its  execution,  the  other  control  dynamics.  These  two  aspects  of 
process  dynamics  can  be  represented  by  two  graphs,  the  data-flow  urapli  and  the  control  giaph. 
respectively  Both  graphs  are  discussed  in  the  sequel 

Physical  attributes  ol  process  component'  describe  each  component  slid)  as  a progiam  01  a 
data  set.  m terms  ot  the  characteristics  tlut  are  ot  inteiest  in  a given  situation  l or  example,  in 
high-level  network  simulation  ol  the  process,  the  physical  attributes  describing  a program  may 
include  an  estimate  ot  the  program  execution  tune,  its  memory  requirements,  and  its  inputs  and 
outputs  Hie  physical  at  tributes  ot  a process  normally  are  lepresented  in  the  form  of  various 
data  structures,  such  as  tables,  lists,  etc 

Next  follows  a discussion  ot  a general  approach  for  graphically  representing  tilt*  two 
jspects  ot  process  dynamics  mentioned  earlier,  inhumation  (low  and  control  dynamics  This 


approach  is  based  on  what  in  the  theory  of  operating  systems  is  known  as  programming  (or 
process l schemata,  lo  simplify  the  discussion,  a one-level  process  model  is  considered  in  the 
sequel:  extensions  to  a two-level  hierarchical  process  model  are  self-explanatoiy. 

( 1 1 Process  Schemata  A Generalized  Approach  for 

Representing  Real-Time  Processes 

A process  schema  is  a representation  in  graphical  form  of  an  asynchronous  process 
consisting  of  a set  of  fu.  tional  tasks  and  control  boxes.  hach  task,  similarly  to  mathematical 
functions,  acts  on  input  arguments  to  produce  a set  of  output  values.  The  process  execution 
logic  defined  by  control  boxes  specifies  the  task  execution  sequences. 

The  input  arguments  of  a task  are  located  in  its  input  files  (data  sets*:  the  output  values 
are  stored  in  its  output  files  (data  sets),  hach  task  in  the  process  must  have  at  lease  one  output 
file  and  may  have  none.  one.  or  several  input  files.  Analogously  to  constant  mathematical 
functions  (i.e..  those  that  have  no  arguments),  a constant  task  is  one  which  uses  no  input 
arguments  and  modifies  every  record  in  all  its  output  files  in  a fixed  and  predetermined  way. 
independent  of  the  current  contents  of  the  output  files.  To  allow  representations  of  iterative 
tasks,  a given  file  may  function  both  as  an  input  and  an  output  file  of  an  iterative  task.  This  last 
feature  max  be  used  to  represent  modifications  (single-  or  multiple-step)  of  the  values  shared  in  a 
data  set. 

All  exogenous  inputs  into  the  process  and  the  endogenous  outputs  produced  by  the 
process  are  represented  by  means  of  the  external  input  and  the  external  output  files, 
respectively.  Thus,  the  interface  of  the  process  with  its  environment  may  be  completely  specified 
by  defining  the  inputs  (including  their  arrival  rates)  which  are  pumped  into  the  external  input 
files  and  similarly,  the  outputs  < including  their  production  rates)  which  are  put  into  external 
output  files. 

The  control  mechanism  of  the  process  manages  the  process  execution  logic  by  changing 
the  task  states  and  determines  alternative  execution  paths  (task  execution  sequences).  The 
control  mechanism  is  defined  by  a network  which  contains  nodes  of  two  types,  control  boxes 
and  functional  tasks  (from  now  on.  functional  tasks  will  be  briefly  called  tasks). 

In  this  network,  every  node  representing  a task  must  have  a single  exit  point  connecting  to 
a path  (outpatht  which  leads  either  to  the  successor  task  or  else  to  a control  box;  furthermore, 
every  task  must  have  at  least  one  entry  ,•  ''>nt.  each  such  point  corresponding  to  an  incoming 
path  < inpath). 

One  can  divide  the  control  boxes  of  a process  model  into  three  classes  according  to  the 
number  of  inpaths  and  outpaths  that  they  possess: 

( 1 ) k.ntry  control  boxes  such  a box  has  zero  inpaths 

(2)  kxit  of  termination  control  boxes  each  of  them  has  zero  outpaths 

(3)  Intermediate  control  boxes  each  ol  them  possesses  at  least  one  inpath  and  at  least 
one  outpalh. 

kvery  process  model  must  have  at  least  one  entry  control  box  and  at  least  one  exit  control  box. 

An  inpath  to  a control  box  may  emanate  from  a task  or  from  another  control  box: 
similarly,  an  outpath  may  point  either  to  a successor  control  box  or  to  a task. 
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A I any  instant  dining  piogram  execution.  the' state  ot  a loutiol  l»>\  is  'ijii-i  ? r . i a 
non  negatixo  integer  I which  tells  how  mans  uh'ImI  . m i I p.i i I >•  ai  •’  ciuiciilly  opent  t ! i-  list  "I  • >;  ii 
control  outpaths.  anil  :m  oaolt  upon  ouip.ith  a sp.-cilied  111110  il<  In  i-datnc  in  virn  absolute 
tmto  point  The  zero  state  means  that  all  eontiol  outpaths  .tie  eiuieiitlv  blocked.  wind  unphc' 
that  any  process  execution  path  passmj*  through  the  umliol  l>o\  in  /.‘<o  state  i.i"n*i!  pj.igic  ' 
hex  otul  the  hox  until  its  state  attains  non-zeio  value  \ non  /eio'  state  ol  a mntiol  lev 
i ml  teat  eit  hx  the  positive  integer.  I.  implies  th.tt  I c‘>nttol  ompailis  ate  uttcn'lx  opi  n \ 
companion  list  tells  which  control  outpaths  belong  to  he  set  l open  outpat1  'lot 

implementation,  the  easiest  thing  to  Jo  is  toi  eaih  t*ox  to  mamt  m 1 I is'  ot  ail  its  .ontml 
outpaths.  ami  then  to  imlicate  by  an  outpatli  stuns  !>u  v.  * > • 1 1 >•  • • <;  1 v 1 1 . o-tpiiu  ,s  , i<  ••  .1 

own  • 


Ihe  executioii  >t*ic  xxorks  as  tollovxs  At  the  initial'/  ition  ot  pi.n-ss  ex*  culior,  at  Sc.i'l 
one  entry  control  bo\  is  assigned  to  a non- /on > st  »io.  all  othet  lontro1  boxes  an.  put  1;  to  tiie 
zero  state.  When  a control  hox  is  ■•niei-J  durrm  pme-s  ■xeiut'oi:.  the  toll,  wm'  sj.p,  .11. 
carneii  out: 

(It  The  predecessor  control  box  is  appropnatelx  modilieJ  01  r.  si't.  xxi  , :vn.%al!_\ 

amounts  to  closing  the  path  just  used  in  oulei  to  e u.  i * |.v  suinnt  1 \n  .ntrv 

control  hox  skips  this  step.t 

(2»  The  state  ot  the  current  control  hox  is  analyzed  ind.  :l  in lessaix . .l.atigxd  in 
closing  or  opening  control  outpaths  and  '>x  lompiitmg  tin  delr. •>  toi  eadi  pit'*  past 
opened. 

A process  schema  is  completely  defined  by  means  ot  two  dues  led  graphs.  1 i at:i  How 
graph  and  a control  graph.  I hose  txx  • graphs  are  discussed  next 

(2)  The  Data  Flow  Graph 

The  data  flow  graph  specifies  the  input  domain  and  outputs  ol  each  tasl  m the  pi OiC's 
model.  This  directed  graph  contains  two  types  ot  nodes,  tiles  toi  data  sets),  and  functional  tasks 
(or  operators).  Ihese  nodes  are  interconnected  In  directed  links  (or  edttesl  A direetid  imk  lion 
a File.  F, . to  a task,  I . indicates  that  F,  is  in  the  domain  ot  I . similarly . a dm  clod  link  innn  1 

to  a file.  F;.  shows  that  I ; is  in  the  ranee  ot  task  I \s  alieadx  indt  ite  i.  the  domain  ol  .1  task 

max  he  empty  or  may  consist  ot  one' or  sexet.d  input  tiles  t!k  1 mgi  in.*x  .niisist  ot  at  least  one 
output  file 

I he  following  del  mil  ions  will  he  used  lor  disiussinc  data  flow  gtapiis.  \ tile  tor  Jita  -et 
will  he  represented  In  the  standard  llov.  chartme  s\  ml<o|  !<>i  tdc'  1 1.  si.  will  hi  ii  pi. suited  hx 
a circle. 

The  following  example.  Figures  I 5o  and  I ' ' shows  t lie  data  llov,  ei.iph  and  a companion 
control  graph  ot  a simple  process  model  Ihe  tirsi  lump.  ilhisti.itcs  an  impoitant  pitikiple 
according  to  which  a data  How  path  imm  one  tile  to  anoihet  alw..xs  goes  through  a task  nodi, 
hut  there  tnay  he  no  file  in  a path  between  two  siictcssixe  tasks  itor  example,  tasks  [ , ami  Ti  1 

To  denote  that  there  may  he  a net  loss  ot  records  in  an  input  tile  as  a result  ot  tin 
execution  of  the  task  in  whose  input  domain  the  tile  i>  located  tlv  minus  sign  1 1 will  he  put 

next  to  the  directed  link  from  the  tile  to  the  task,  it  tin  input  tile  is  a lead-only.  no  uniicaUn 
will  appear  next  to  the  directed  lint  A due-. ud  link  xxhuli  umitiois  ,:s  an  ouip.1i1.  Horn  a ta,i 
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FILES  Ft  AND  Fg  ARE  EXTERNAL  INPUT  FILES  FILES  F4  AND 
Fs  ARE  EXTERNAL  OUTPUT  FILES.  FILE  Fy  IS  A READ-ONLY 
INPUT  FILE  IN  THE  DOMAIN  OF  T|. 


Figure  1 5f».  I>aia  Flow  (<ni|ili 


to  jii  output  file  will  always  Ik  associated  with  .it  least  mu*  ot  the  following  two  symbols,  mi 
asterisk  or  a plus  sign  A11  asterisk  denotes  that  the contents  ol  the  output  file  may  he  modified 
during  the  execution  ol  the  task,  the  plus  sign  tells  that  the  execution  of  the  task  may  cause  a 
net  gain  in  records  in  the  output  tile.  'I he  rules  wlueli  speedy  the  data  llow'  fiom  an  input  file  to 
output  tiles  as  a result  of  the  execution  ol  a task  belong  to  the  lunctional  definition  ol  a task. 

(3)  The  ( ontrol  Graph 

This  directed  graph  describes  the  execution  control  logic  in  the  process.  It  consists  of 
nodes  of  two  types,  one  representing  the  lunctional  tasks  (same  as  in  the  data  flow  graph)  and 
the  other  represents  the  control  boxes.  As  discussed  earlier,  every  control  box  in  a process  model 
is  of  one  ol  the  following  three  types:  an  entry  control  box  tit  has  no  inpathsl:  an  exit  control 


CONTROL  GRAPH  OF  A PROCESS  WHOSE  DATA  FLOW  GRAPH  IS 
SHOWN  IN  FIGURE  ! C f,  CONTROL  BOX  Ct  IS  THE  ONLY  ENTRY 
CONTROL  BOX  IN  THE  PROCESS  C7  IS  THE  ONLY  EXIT  NODE  ALL 
OTHERS  ARE  INTERMEDIATE  CONTROL  BOXES. 
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Ini',  HI  has  no  nnlpalhsl  oi  .in  mlriiiKili.lL-  eonliol  hov  HI  has  al  leasl  oik'  inpatli  .mil  ,il  Ic.i.sl 
one  duip.iilii.  Note  Hi, K | ho  luncDutiai  tasks  air  enmpletely  •'I  nr  Med  Iruni  I tic  system  environ 
n ir  it  l in  i hr  sense  that  even  possible  execution  p.illi  uuisl  Marl  with  an  entry  eon  I rot  bov  .mil 
end  with  an  evil  control  Lov.  I.vo  kinds  ol  symbols  aie  used  In  repiesenl  Die  nodes  of  a eonlrol 
Lii.i pJi . I'eel.meles  irpieseni  Die  control  Loves,  circles.  as  I .e lore,  lepiesenl  I1111el1011.1l  (asks  A 
• oiiiplrle  speeilieallon  o|  process  control  ie<|inies  Dial  Die  sialiis  of  control  Loves  he  properly 
nnliali/id  and  Dial  III.-  .ilp>  >i  11  Imis  y>o»ei  ntriv  Dir  fuiirlioii.il  behavior  of  ronliol  ho  vs  he 
speed  ird. 


i ll  I’lofiani  (i.".ipli  and  Die  Mavnnally  I’aiallel 
l*i  rd>\  rssi  ir-Sii,. i essi  n ( ir.ipti 


I hr  appio.ieli  iised  |o  irpirsud  pioress  lopoloeies  in  Die  drsijin  ol  Die  process 
. on  si  1 1 k I id  n piorrdiirr  described  line  is  mmr  ivsineled  in  Die  sense  Dial  il  is  based  on  iwn 
more  speci.di/ed  eupli'.  Dir  .o  . ailed  pioeiain  erapli  and  Dir  iii.ixiiii.illv  parallel  < delerniin.ite > 
pirde,  rssoi-siieressoi  L’laph  o|  a proei  mi  III.-  second  of  Diese  (wo  er.iphs  n tnoie  yeiiei.il  Ilian 
Die  III  si  m Die  sense  Dial  Dir  lns|  i.iii  Ik  dimed  lioni  IL.-  second.  Ifolli  piapli.s.  Iiowrvei.  ale 
driiy.ihle  lioin  Die  inloi niaiion  mill, nurd  in  Dir  dala  Dow  and  ronliol  graphs. 

I lie  program  i.’iaph  is  a dinvlrd  uiaph  wlinli  defines  all  alternalivr  rvrrnlioi)  paths 
Ih roue h (Dir  model  ol  i a pion.ini.  Ils  nodes  lepiesenl  Die  (asks  iliinrtiou.il  code  sepnientsl 
miisDltiiinr  Dir  propi.iiii.  | m piorcss  ronsinn  lion  purposes  Dir  follow  mi-  assuinpiidiis  are  made 
ahonl  Die  pioei.mi  souiIiih  and  Dins  aboiil  ils  proei. nn  er.iph 


(I)  lhe«e  lx  a single  entiv  node  I task  I 


t2>  Ilk'll'  lx  .1  single  CMl  llodc  H.lxkl 

i.tl  Ihere  are  no  dossil  loops  l lit  i miizIi  the  nodi' % |ie.  ill  piogram  loops  innsl  ocelli 
within  imliMiln.il  nodi-s  « i.:sksi| . 

I In?  m.ixmi.ill>  parallel  pii'di'.i'ssoi  sm^issot  eiapli  o|  .1  progt.im  coni. mis  mote 
mti'i m.i! ion  tli.ni  the  piogram  giaph.  I*»i  each  alternative  pith  in  the  program  graph.  it  shows  .ill 
parallel  t.isks  ot  strings  ot  sm.li  lasts  which  i.iii  !'.•  "mv  mi I iotKtni"nlly  without  an>  loss  m 
process  dctcnniii.nK>  I he  dexdiptor  "maxmwllv  paiallel"  s.ns  th.it  .m>  other  simikit  graph 
showing  .tore  |*.ii.illehsin  would  not  etui  mtei  p»«»<  ess  Icleimtn.incv  tie.  program  output  would 
not  he  independent  ot  the  execution  sequence  ot  p.ir.illd  task  groups).  I urtheimoie.  tilts 
nuxmiallx  parallel  predecessor-successot  graph  is  the  simplest  possible  ot  all  such  u.-terminate 
graphs.  as  other  sudi  graphs  would  h<-  more  complex  h>  having  mm  .•  edges  tlmls)  than  the 
simplest  one  In  that  sense,  the  < ax.m.ilh  p.ii.dl- 1 tdi  teinnn.ilei  ptedecexxor-xtic lessor  graph  is 
unique  tor  a given  program  model 

lo  illusti.ite  the  idatioiiship  he  tv  een  the  tn.ixim.ill>  parallel  predecessor-successor  graph  ot 
a process  and  the  resulting:  piogram  graphs.  consider  the  example  given  in  I mure'  15k.  The 
•roeexx  model  shown  in  the  m.i\:ni.tll>  pirallel  predecessot -successor  graph  possesses  two 
iiiutiidlK  exclusive  execution  paths  the  first  one  passes  through  nodes  I.  r.  3 A and  dB.  and  4. 
the  other  path  jjoes  through  nodes  I.  4.  and  x I he  onl>  p.ii.illehsitt  that  exists  m the  model  is 
contained  in  the  first  path  inodes  4 \ and  eBl.  I ’sing  the  gt.ipli  on  the  lelt.  one  can  construct,  as 
shown  m I- ittur—  I 5>s.  two  pioguni  staphs  I his  example  illustrates  two  points,  lust,  the  program 
graph  is  not  unique:  xc\ondl>.  a piogram  graph  contains  less  mlotmalion  about  the  process  than 
the  maximalK  parallel  predecessm-suc  cessot  giapli  trom  which  the  lot  liter  has  been  domed. 

File  program  graph  has  been  used  m process  constitution  maml>  to  analwc  whether  a 
program  does  not  exceed  the  c.ipacit>  ot  j 1)1*  \|  Processing  I lenient,  the  maximalK  parallel 
predecessor-successor  graph  to  construct  the  task  execution  sequence  tables  and  the  task 
enablement  mnlitinns  tor  the  DP  M I xecutive  Both  gt  iphx  ate  lurthet  discussed  in  the  sequel. 

2.  Process  Development  Methodologv  Based  on  I op-Down 

Modeling  and  Successive  Simulations 

I he  process  construction  procedure  under  considei.ition  is  intended  to  be  applied  to 
process  development  that  is  primanlv  b ised  on  top-down  modeling  and  on  successive  simulations 
ot  the  entire  real-time  process  I his  appio.u  h still  peimitsocc.isiim.il  botto  ti-to-top  development 
ot  individual  process  components  whenever  it  appears  to  be  pi.ietie.ill>  adv  mtageoux:  however,  at 
ain  stage  ol  process  development.-  it  must  possible  to  integrate  individually  developed 
components  into  the  overall  piocexx  model  and  test  them  in  the  ximul  ited  environment  ol  the 
DP  M network 

Siikc  the  basic  process  construction  procedme  interacts  with  successive  simulations  ot  the 
process  m the  sense  that  the  process  const  rue  I ion  outputs  jre  to  be  simulation  inputs,  a good 
understanding  ol  the  assumed  simulation  inethodolog>  is  essential  to  understanding  of  proee's 
construction.  Iheretore.  this  siii'seition  is  dedicated  to  a teview  oi  the  piocexx  development 
meth«Hlolog>  based  on  sticeessive  simulition' 
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As  already  noted,  there  is  a second  graph.  related  to  the  program  graph,  which  also 
belongs  to  the  computer-independent  model  and  is  used  to  define  all  possible  parallelism  in  the 
execution  of  a program'  the  maximally -parallel  precedence-successor  graph  of  the  program.  Note 
that  the  topological  model  of  a piogram  obtainable  from  either  one  of  these  program  graphs  is 
more  general  than  that  allowed  for  structured  programs.  The  program  graph  of  a structured 
program  is  a special  case  of  the  graphs  described  above  because  it  required  that  all  nodes  be 
completely  ordered. 

The  underlying  reason  for  introducing  computer-independent  models  is  that  such  models 
constitute  a convenient  medium  to  study  the  effects  of  changing  the  computer  hardware 
parameters  on  the  same  process  (system  of  programs I.  Past  experience  has  indicated  that  the 
most  efficient  approach  is  to  construct  a computer-independent  model  for  the  applications 
(mission i part  of  the  process  and  then  to  use  the  data  base  thus  generated  to  get  computer- 
dependent.  running-time  models  tor  various  l.xccutive  and, or  computer  configuration 
combinations  as  needed.  Such  a process  of  transitioning  from  computer-independent  to 
computer-dependent  models  can  be  considerably  accelerated  by  a computerized  procedure  which 
reads  (lithe  computer-independent  description  of  a program  and  (2)  the  parameters  of  the 
computer  under  study  and  then  produces  a computer-dependent  description  of  the  same 
program.  Such  a computer-dependent  description  of  a program,  to  be  discussed  next,  is  called  its 
synthetic  model. 

<2?  Synthetic  Models 

As  noted  above,  the  synthetic  model  of  a program  is  produced  by  merging  two  sets  of 
input  information,  one  of  which  desciibes  the  computer  under  consideration:  the  other  describes 
the  computer-independent  model  ol  the  program.  Thus,  a synthetic  model  always  implies  a 
specific  computer.  Synthetic  models  are  used  to  represent  programs  both  in  system  network  and 
m functional  simulations.  In  the  latter  case,  a synthetic  model  usually  constitutes  just  a part  of 
the  functional  model.  A complete  synthetic  model  of  a program  contains  the  following 
information: 

( 1 > Program  execution  control  data  (scheduling  rates,  priority,  etc. I 

(2?  Its  memory  requirements  stated  in  terms  of  the  word  count  for  the  com?  liter  under 
consideration 

(3?  Specification  of  all  feasible  execution  paths  through  the  program  graph  (including 
the  logical  conditions  or  probability  for  each  path? 

(4)  Predecessor-successor  graph,  indicating  the  partial  ordering  of  and  parallelism- 
program  segments  (tasksi. 

(5?  I stmiated  limits  on  the  running  tune  for  each  feasible  path  and  for  the  individual 
tasks  constituting  the  program 

in?  Descnption  ot  the  program  I (). 

(3)  Functional  Models 

Functional  models  ol  tasks  and  programs  are  used  mainly  in  functional  simulation.  For  the 
time  being,  it  will  suffice  to  think  ol  a luiut tonal  simulator  as  being  an  extension  of  the  System 
Network  Simulator  in  which  synthetic  models  have  been  replaced  with  their  functional  counter- 
parts. The  consequence  ol  this  replacement  is  that  functional  simulation  can  produce  and 


; •*'  '.i'ih-  •l.ii. i i»i  ilu-  mimiiI.iu'iI  s v' ••  i r i m . whereas  system  nctwoik  simulation  is  -eslneted 

* m dimmu  li.c  . .ihsli.icll  rcpii-scul.il  ions  n|  lliis  data. 

\ 'mi.  limul  model  hi  .1  pm)',. mi  includes  its  synthetic  model:  in  addition.  il  must  contain 
11  i'  't  in'll. il  model  hi  t lu.-  .ih'iiiiflim  inr  compuiat  ional  procedure)  which  is  to  be  represented 
' ’*•  'hi  pio.eiam  \l? in 'iii’h  .1  limclinii.il  model  may  he  (list  a crude  version  of  the  algorithm 
1 i'f  ■>•  .'.huci  n siill  iiiie.i  In-  able  to  icpieseiii  certain  salient  features  of  functional  behavior  that 
■■  ■ • ’ i lls  1 S|  I"  the  s’.sii-m  ilemiici  As  nolal.  one  imporianl  eliaraeterislie  ol  a functional 
■Hi*  i ! isl nn'in 'iniM'  il  fioni  a syiitheti*.  nn >*ti*l . I-  that  il  hamlles  the  actual  value  data  of  the 
i>,  cl.  I i i'ii  in.  m ci  mil  asi  i.i  a nt  het  ic  nioilel.  which  handles  only  the  diiiimiy  (ahslracl) 
an  tiior'.i.  ol  the  same  data  I ur » hoi  more,  a functional  model  may  know  about  the  true 
,t,i|.  .>!  die  siiniil.iied  system  and  its  environment,  whereas  an  analytic  model  (discussed  next)  is 
i 'I  c,  I. now I. -dee  and  leains  ahotil  the  state  <>l  the  system  or  its  environment  only  through 
ih  m. . ii 1 1 1 ■ !■  ie  ,m  contaminated  into! iii. il ioii  that  would  flow  into  and  through  the  actual 

s\  •(,  m 


I,  nn aii.it  timcliou.il  model  pun-rains  may  consume  or  produce  actual  value  data  t)!  the 
sifintat.. .i  " deni,  may  !>e  modeled  on  many  diflei-  nl  lunctional  levels,  and  may  have  access  tea 
Ui  mi.  m man. >n  about  the  true  stale  ot  the  system  and  its  environment.  Such  a model  always 

, .nit  lies  .i'  its  k . a n ■!  the  s v nt  lit  ic  nioilel  of  l he  same  program. 

i 5 : \n  -K  | ;t.  Models 

lit.  i inal  miplv'uieniation  oi  a piueiam  or  task  on  the  target  computer  represents  its 
it;  .!•  ic.  h i,!  I Ii  make*,  lelaiio  lv  little  diflerence  whether  this  model  has  heen  coded  in  the 
....  mi  I i insm.it'c  ot  (In  computet  uudci  consideration  or  a high  order  language  has  heen  used 
l oi  1 1 ; ; i jmip.isc  i W hat  Is  nnporiant  in  the  latter  case  is  that  the  appropriate  language  translator 
t.a  icnvi  coii’pttNa  exists,  t * m I lici  inoie.  the  analytic  model  does  not  have  to  represent  the 
; i it  i a i.i  i .-  ..  ,’i  -at ",  ■ ,!  I In-  i l:M  m il  h iii  oi  ot  a computational  procedure:  it  may  just  express  a crude 
■ ■:  a..),  ,,i  i he  aleornlim  t procedure i Wli.d  distinguishes  the  analytic  model  from  the  last  two 
nn  mi  .li»,  u-,s.-,i  is  Hi, ii  il  posscses  no  synthetic  kernel  Iml  describes  it  own  dynamic 
i i-e  ''chip  vxiYiitcd  on  the  t.iiect  machine  or  on  its  Instruct  ion  I .eve  I Simulator. 

!-,  iii  l.-s -|,  piii.nl  ol  realtime  punesses  lot  1)1’  M.  the  strategy  should  be  to  introduce 
i i.  i,  ; .. . s as  late  as  possilde  m (lie  development  cycle:  they  hccome  tmavoidahle  in 
i ' ,n  c t.-t  b.-. Is  and  nt  pri deployment  acceptance  tests.  Otherwise,  due  to  ti  e limitations  of 
I'd’  M net  wot  I.  to  support  its  own  softwaic  development,  the  bulk  of  developmental 
mi. ,d  .Ii. ,'i I I i.  c.iiiinl  out  on  a liost  machine,  thus,  those  simulations  will  he  cither  of  a 

.»  , i . >i f.  oi  oi  ,i  Iiiik  iKMial  (vpe.  One  separate  type  o|  application  where  analytic  models 

cm.  : mi!  ,,  msinii  l ion- lev  el  simulation  ol  individual  software  modules  to  validate  synthetic 

i . I > : <i  ■.ti-t’i  net  vo, 1 1.  and  I mu  lion. il  simulations. 

• ...  i - ! ■ > '"111111,11  i/i- . the  coihiiion  oi  models  a. nl  shows  l licit  temporal  ordering  during 

: ’ * i : • , ! >p;nc.ii 

/>  Simulation  limit’*  am!  Sitmiltiltm 

1 1.  i> ,!l, , in.-  i • . i - 1 . -.iimilal uni  modi -.  ne  associated  with  the  proposed  methodology  for 
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Figure  1 59.  Evolution  of  Process  Model 


System  network  mutilation 
Functional  simulation 

Instruction  (or  Processing  Element  level)  simulation 
Hybrid  analytic  simulation. 

I lie  lirst  three  simulators  are  ot  discrete-stochastic  type,  such  a sunulatoi  can  be  built  around  a 
common  software  package  which  is  independent  from  the  particular  simulation  mode,  model,  or 
the  pr<  Idem  to  which  it  is  to  be  applied.  This  package  provides  a nucleus  of  basic  subroutines 
for  simulation. 

Next  follows  the  description  of  the  four  canonical  simulation  modes  and  of  the 
corresponding  simulators.  Figure  160  shows  how  these  four  simulators  are  interrelated:  in 
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Figure  1 60.  Overall  Structure  of  the  Relationship  Between  System  Network. 
Functional  and  Instructional  Level  Simulators 


particular.  it  shows  t Ik*  commonality  ol  simulator  components.  Figure  !(>)  shows  tne  use  oi 
these  lour  simulators  in  the  evolutionary,  top-down  process  development  lliiougli  siaussive 
simulations. 

ill  Si  tern  Network  Simulation  and  Simulators 

I’tocess  development  starts  with  system  network  simulations  on  the  host  machine.  The' 
System  Network  Simulator  is  used  as  the  simulation  tool.  I he  objectives  ol  system  netvvoik 
simulation  are  to 

B dance  the  hardware  and  validate  its  sufficiency 
Validate  the  functional  design  of  the  I xecutivetsi 

Validate  the  correctness  of  the  process  control  data  (schedules,  description  of  the 
process  structure,  etc. I 

hvaluate  the  “goodness”  of  process  structure  and  hardware  resource  allocation  to 
process  components. 

The  main  models  to  he  used  in  system  network  simulation  are: 

Process  F.xecutive(s)  to  he  modeled  functionally 

Hie  intermodule  1 O and  the  communication  with  system  environment  (sensors  and 
actuators!  to  he  mooeled  synthetically  in  terms  of  dummy  messages 

Mission-oriented  avionics  programs  to  he  modeled  synthetically. 

The  simulation  output  data  contains  information  on: 

Hardware  resource  loading  and  usage 
information  flow  through  the  Inis  system 

The  demand  on  system  resources  hy  individual  process  components 

Dynamic  behavior  of  program  execution,  such  as  scheduling  patterns,  meeting 
deadlines,  synchronization  and  conflict  resolution  between  concurrently 
executed  process  components. 

Avionics  system  engineers,  computer  system  designers,  and  Fxeeutive  designers  are  the  persons 
principally  interested  in  system  network  system  simulation. 

(2i  Functional  Simulation  and  Simulators 

Alter  system  network  simulations,  the  next  stage  in  the  evolutionary  process  development 
cycle  is  functional  simulations.  As  noted  previously,  the  main  difference  between  system  network 
and  functional  simulations  is  that  the  simulation  of  the  first  type  models  the  10  traffic  through 
the  system  in  terms  of  dummy  messages  (described  in  terms  of  their  frequency,  si/e.  origin,  and 
destinations),  whereas  the  simulation  of  the  second  type  in  addition  handles  the  actual  value  data 
ot  these  TO  messages.  Hence,  the  functional  simulator  must  be  provided  with  a simulation  driver 
which  accesses  or  generates  the  process  (system)  environment  data  and  then  pumps  it  into  the 
simulation  process,  sunilarlv.  it  needs  a model  of  the  process  (system)  response  mechanism  by 
means  ot  which  the  process  (system)  reacts  to  anil  affects  its  own  environment.  Tor  this  reason, 
functional  simulations  are  useful  through  that  phase  of  process  development  during  which  the 
mission  functions  and  algorithms  (including  their  implementations)  are  tested  and  evaluated.. 


,.m  •'  pr,Vl'ssor,  °hserwr  introduced  into  the  functional  simulation 

IUil  ' °,’SC'U‘I  'N.  '*  mcJunism  wll',~  lU'K-liuii  is  to  observe  and  record  the  true  state  of 

oV!hm!!rnI  ,Wn  h ,lK  °h'mvr  tan  aiu!  thc  corresponding  actual  inputs  and 

I t'u  r .kcss.  1 1, esc  recordings  are  done  tor  post-simulation  analysis.  Ihus.  the  mission 

les,  I el  d , L PrUCl>SS  " lH‘  nK‘JS,,rc‘'-  •Sudl  a»  •*«*»*»*  allows  maintenance  of  the 

. e , xrT  "*  Pr<Ul'SS  alm>*  Ms  entire  design  and 

ini|  li  iik  niation  cycle  figure  162  summan/es  the  relationship  between  the  process  under 

shows’^e  pm11"  7,Vlr■,^me,,,•  d,Ui  ,lK‘.  ,H,K0SS  «,  the  environment.  It  also 

"Mer.on.i.iiinlcatm.rimkv  ‘'IW  ",lnrm:"",n  *°r  neilorma.uv  evaluation  from  several  system 


I lie  main  object ives  ol  turictional  simulation  are 
I urt her  development  or  the  Kcculivc 

Development  ot  algorithms  and  software  for  avionics  functions 
Validation  ol  program  correctness  and  software  reliability 


» uiktional  simulations  arc  run  on  the  host  computer.  The  following  models  are  used: 

Process  I scunners)  to  be  modeled  functionally,  possibly  with  greater  detail  titan  in 


systi  network  sir,,  ilalion 


Die  intermodule  10  and  the  communication  with  system  environment  to  be 

modeled  in  part  functionally  < messages  whose  values  are  unknown  shall  be 
modeled  synthetically) 
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Mission  I million  programs  to  lu*  modeled  lunetiomilly 

Process  environment  and  response  data  to  he  modeled  lunetionally  by  geneialing 
the  aetual  values  lor  exogenous  inputs  and  endogenous  outputs. 

I uiivtiou.d  simulation  produces  the  following  types  of  simulalion  output: 

( opies  ol  exogenous  inputs  into  the  process  from  its  euviionment  (such  as  ladar 
ri  turns  > 

1‘ioeess  reipiests  tor  environmental  data  tsiicli  as  radar  orders l 

Process  response  outputs  istieli  as  the  proeess-to-ai lualor  signals) 

I lie  process-internal  tunctional  data  (such  as  the  information  hemp  *.  \cii.nigcd 
hetvveen  individual  functions,  tasks,  or  other  process  modules) 

\ll  output  data  obtainable  from  sy  tern  network  simulation  such  as  system  biding. 

1 O tialtic  through  it  or  lurutional  behavior  ol  the  I xecutive). 

Note  that  the  lit't  three  output  types  are  observed  and  recorded  by  the  Process  Obseivcr  I he 
re 'orded  output  can  be  analy/ed  alter  simulation  to  determine  the  m.ssioit  ellectiveness 
neiioimaiiie  ol  the  proiess.  which  constitutes  a capability  that  greatly  facilitates  development  o' 

! ussion  aleoi ithtits 

i.i)  I nst i Us. t ton  I.ev  ‘I  Simulation  and  Simulators 

Simulation  (simulators!  ot  this  type  in  l)P  M work  is  also  called  Processing  l lenient 
simulation  (simulator!,  ioi  it  is  used  to  simulate  the  program  execution  on  a single  Processing 
•i.-meni  « PI  > A host  computer  is  used  t<  run  instiuctioit-level  simulations.  In  the  software 
'•..■ss  development  methodology  describe  I here,  the  u-c  ot  instruction-level  simulation  is 
limited  it  i'  to  Iv  applied  prim  inly  to  validate  models  lor  the  other  types  of  simulation  and 
• > c tsionally.  to  develop  soltvvarc  modules  for  the  target  computet  before  the  lottcr  becomes 
av.n!..  >!e 

I he  pioecss  program  that  is  to  he  simulate d on  the  Instruction  Level  Simulator  must  he 
iic  .t.-liei  analytically  (i.e  . tne  actual  program  i*  used).  As  noted  previously,  this  program  m.tv  be 
wiitteu  in  the  assembly  language  ot  the  target  computer  or  preferably  in  a higher-* >r-L,  iatiguage. 
*.  fei’ding  on  the  av.nl  ibilty  of  such  a language  and  its  compile!  lor  the  target  coit.puvr 
! iiitietinote.  the  program  does  not  have  to  reptesent  tile  ultimate  vetsion  »>l  an  algorithm 
t procedure l.  on  the  coiittary.  an  analytic  model  olten  icpiesenls  picliminaty  vcision  ot  the 
deonthm  < procedure ».  One  important  characteristic  ot  analytic  models,  already  noted.  tti.it 
Mi.li  a model  describes  its  own  uiiHuue  chaiacteii-tics  either  by  being  simulated  on  an 
Instruction  I cvcl  Simulator  or  by  being  executed  on  the  taig*-t  machine. 

The  objectives  ot  instruction  level  simulation  in  process  development  are: 

Program  validation  on  the  most  computer 

Improvement  ot  synthetic  mode's  tsiidi  as  program  running  times) 

Detailed  investigations  ol  compute!  architecture  to  tit  hardware  combination  : 
process  requirements. 

I,  sti uc lion  level  simulation  can  produce  the  L.Howiiig  outputs  ol  interest  to  process 
d.  slgl.  .! 


’ - X 


High  fidelity  data  oil  the  tuning  of  simulated  program 

Detailed  maps  of  memory  usage  in  the  simulated  computer 

Memory  and  register  dumps  (snapshots)  of  the  simulated  prugiam  execution 

The  actual  outputs  of  the  simulated  program. 

(4)  Analy  tic  Hybrid  Simulation  and  Simulatois 

Simulation  ol  tins  type  is  used  in  the  laic  stages  of  process  development.  It  luiis  on  the 
target  computer,  i.e..  on  the  whole  DP/M  network  oi  on  a representative  portion  of  this  system 
such  as  an  Aftiniiy  Group.  Similarly,  an  entire  process  or  a representative  porti-m  of  it.  such  as 
an  avionics  function,  is  simulated.  Furthermore,  simulated  or  real  sensois  actuators  (i.e..  the 
process  environntent/response)  are  applied  to  stimulate  and  drive  simulation  which  can  proceed 
in  real  tune  or  in  interrupted  real  time  (as  in  hot-hench  test-bed  simulation),  depending  on  the 
configuration  of  the  simulator  hardware. 

The  term  “analytic'*  in  the  description- of  this  simulation  denotes  the  fact  that  the  analytic 
model  of  the  entire  process  is  to  be  used:  the  other  term,  hybrid,  emphasizes  that  both  analog  as 
well  as  digital  equipment  may  be  used  in  the  simulator  hardware.  The  digital  poition  of  hardware 
may  include  other  computers  besides  the  target  DP.'M  n-.’twoik. 

in  summary,  anaiytie.'hybnd  simulation  will  be  run  on  the  target  computer  < DP/M  system 
or  a substantial  portion  of  it).  Additional  analog  anil  digital  equipment  may  be  needeu  to  drive 
and  control  the  simulation  process.  t»*  provide  exogenous  inputs  for  this  process,  and  to  consume 
the  produced  outputs  in  the  closed  loop  with  tfie  piocess  environment.  Two  types  of  haul  ware 
configurations,  depending  on  whether  the  simulation  purpose  is  a lahoratorv-like  test-bed  exercise 
or  a test  of  the  (pre)deployed  system  are  typical: 

A hot-bench  test-bed  or  a hrassboard  hybrid  configuration,  including  j driving 
(process  environment  simulation)  subsystem 

(Pre)deploymcnt  configuration  ol  the  target  computer,  including  the  standard  test 
equipment. 

The  uses  of  analytic  hybrid  simulation  are: 

Final  process  validation 
(Pre)deploy  ment  ..ccoptaiico  tests 

Improvement  and  validation  of  models  lor  system  network  and  functional 
simulation. 

A subsystem  loi  collecting  and  recording  simulation  output  (the  process  observer)  is  still 
needed  in  tills  type  of  simulation.  However,  its  use  will  have  to  be  carefully  restricted  in  order 
not  to  noticeably  affect  the-  real-time  performance  ol  the  process  under  test. 

>.  Scope  and  Automation  of  Process  ( 'instruction 

to  det  rmme  the  process  constructor  design  requirements,  the  following  two  basic  issues 
must  be  decided: 

The  scope  ol  functional  capabilities  which  the  process  constructor  is  to  provide 
I he  level  of  .uiiomadon  to  be  built  into  the  process  construction  procedure. 
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Any  particular  solution  of  these  two  problems  affects  the  future  usefulness  of  the  process 
constructor.  The  purpose  of  this  subsection  is  to  summarize  the  approach  recommended  by 
Texas  Instruments  for  developing  the  initial  DD/M  process  construction  capabilities. 

a.  Scope 

As  noted  in  Subs:ction  1X.B.I,  the  scope  of  a process  constructor  is  the  extent  of  process 
construction  functions  and  services  that  it  provides.  To  review  and  illustrate  the  meaning  of  the 
above  concept,  consider  two  extreme  cases.  In  the  first  case,  the  process  constructor  is  a 
standard  linking  loader  which  can  perform  the  four  basic  program  linking  and  loading  functions: 
memor>  space  allocation,  resolving  symbolic  references  between  object  decks  (linking),  adjust  all 
address-dependent  parts  of  the  program  (relocation),  and  physically  load  instructions  and  data 
into  memory.  In  the  second  case,  consider  an  elaborate  process  construction  system  which, 
besides  performing  all  functions  of  a simple  linking  loader,  is  capable  of  optimizing  the  process 
structure,  determining  the  best  hardware  configuration  (i.e.,  switching  hardware  to  software),  and 
generating  all  F »ecutive  data  needed  to  control  the  process  execution  in  real-time.  There  are 
many  possible  design  possibilities  between  these  two  extremes.  One  such  choice,  which  is  similar 
to  DP/M  process  construction,  is  shown  in  Figure  163. 

Determination  of  an  appropriate  scope  for  a process  constructor  under  development  is  an 
important  design  decision;  it  affects  the  cost  and  time  required  to  develop  the  process 
constructor  as  well  as  its  operational  usefulness  after  it  has  been  completed.  To  determine  a 
suitable  capability  scope  for  the  DP/M  process  constructor,  the  following  factors  were 
considered: 

Essential  functions  of  process  construction,  especially  those  that  are  peculiar  to  the 
DP/M  hardware  architecture  and  to  the  design  of  its  Executive. 

Features  which  make  the  use  of  a process  constructor  more  convenient. 

The  following  process  construction  functions  have  been  identified  to  be  essential: 

Process  Analysis:  (a)  decomposition  of  a logical  (computer-independent)  model  of 
the  process  into  computer-dependent  programs  such  that  no  program  exceeds 
the  capacity  of  a DP/M  Processing  Element:  (b)  validation  of  the  structural 
correctness  of  individual  programs:  (c)  construction  of  the  I/O  traffic  model 

Process  Synthesis:  (a)  derivation  ot  an  optimal  hardware  configuration;  (b)  optimal 
assignment  of  Processing  Elements  * orr-  -urns  (which  can  also  be  viewed  as  a 
mapping  of  individual  programs  ».«t<  th*  Processing  Elements  of  the  der.ved 
hardware  configuration). 

Remarks' 

As  pointed  out  in  Subsection  IX.B.5.  both  optimization  problems  are 
equivalent 

" Optimal  hardware  configuration  does  not  imply  an  extreme  usage  (saturation) 
of  hardware  resources:  on  the  contrary.  si..je  hard.vare  overloading 
reduces  (re)programmability  of  the  process  software,  the  Process 
Constructor  must  prevent  this  from  happening 

Automatic  generation  of  all  process  data  needed  either  for  process  simulation  or  for 
actually  running  the  process  on  the  target  DP/M  network  in  real-time. 
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Figure  163.  Procew  Construction  of  Moderate  Scope 


Performing  all  model  (process)  linking  and  loading  functions  for  simulation  on  a 
host  computer  or  on  the  target  DP/'M  network. 

Automated  generation  of 

Process  documentation 
Computerized  data  base 

Capability  to  modify  an  already  constructed  process  by  using  the  computerized  data 
base  preserved  in  process  libraries 


b.  Automation 

Definition  of  process  construction  automation  levels  determines 

The  function  of  the  process  designer  (human)  in  the  process  construction  procedure 
The  amount  of  manual  work  involved  in  such  a procedure. 

The  purpose  of  this  subsection  is  to  analyze  the  (actors  that  affect  the  automation  of 
process  construction  and  to  suggest  a recommended  approach,  in  Honey  well's  study  of  DP/M-like 
computer  systems  | Reference  (3)|.  the  problem  of  automating  process  construction  was  mainly 
viewed  as  the  problem  of  deciding  which  process  construction  algorithms  and  procedures  should 
be  computerized  and  which  one  should  be  carried  out  manually.  There  the  attention  was  focused 
on  algorithms  because  at  that  time  they  had  not  yet  been  studied  in  sufficient  detail  to  fully 
understand  the  technical  and  economical  feasibility  ol  their  computerization.  On  the  other  hand, 
the  automation  of  process  construction  was  not  viewed  as  primarily  being  a system  problem,  i.e.. 
the  problem  of  (a)  providing  the  user  with  computerized  information  processing  facilities  which 
would  minimize  manual  handling  input  and  output  data,  (b)  integrating  the  computerized  process 
construction  algorithms  into  a systun  of  programs  winch  would  intercommunicate  through  a 
computer-resident  data  base,  and  ( c » establishing  an  efficient  man-computer  interface  by  means 
of  the  interactive  remote  terminals  with  te\*  editing  capabilities. 

In  the  course  of  the  work  being  reported  here,  an  ovetall  process  construction  procedure 
for  DP'M  computer  systems  has  been  torn  ulated  (it  is  discussed  in  SuKection  IX.O  and  all  key 
algorithms  of  that  procedure  have  been  identified  and  studied.  Theii  analysis  has  led  to  the 
conclusion  that 

All  identified  algorithms  can  be  computerized  at  a reasonable  cost 

Some  of  these  algorithms  not  only  would  overtax  the  process  designer  it  they  had  to 
be  performed  manually  (the  main  reason  for  this  being  their  highly 
combinatoric  nature)  but  'so  would  be  extremely  prone  to  clerical  errors,  and 
thus  would  tend  to  make  the  resulting  process  unreliable. 

fo  illustrate  the  second  conclusion,  consider  the  work  involved  in  generating  program  graphs 
(trom  the  input-output  relations  between  mdivnlual  process  modules)  and  enumerating  all 
potentially  possible  execution  paths  through  that  graph  Doing  this  manually  fora  small  number 
ol  graphs  ot  modest  size  is  not  an  overtaxing  task  However,  manually  analyzing  a great  number 
ol  such  graphs  in  order  to  enumerate  the  execution  paths  and  then  recording  the  results  is  a 


' Johnson.  M.D..  el  ah:  “All  Semiconductor  Distributed  Aerospace  Pri>cessor  Study."  Vol.  II.  Technical 
Report  AT'AI.-TR-?.t-22f>  (August  l‘)7.t)  prepared  for  (lie  Air  Force  Avionics  laboratory.  Air  Force  Systems 
Command,  by  Honeywell  Systems  and  Research  Division,  Si.  Paul.  Minnesota. 


sell -del eating  clfort.  even  the  analysis  ot  .1  sinjile  graph  of  a meilami  si/e  ( with  more  lltatt  ten 
execution  paths)  is  a time  consuming  task.  Mien,  there  ire  algorithms  whose  manual  execution  is 
piacttcallx  impossible  due  to  the  amount  ol  coinhinatoriis  and  arithmetic  involved  Such 
algouthms  occur  in  connection  with  deteimination  ot  optional  process  striK lures  and  hardware 
configurations. 

The  considerations  discussed  above  have  led  to  the  formulation  ol  the  following 
lecommendations  with  regard  to  automation  ol  DP  M process  construction.  I hese recommenda- 
tions are  stated  below  In  dividing  them  into  two  groups  those  that  are  primarily  concerned  with 
the  automation  ot  process  construction  algorithms  and  those  that  apply  to  the  automation  of  a 
process  constructor  viewed  as  a system  in  which  man  interfaces  with  computer. 

Hie  recommendations  tor  automating  algorithms  are: 

1 1 1 All  algorithms  and  procedures  should  be  computerized,  the  designer's  role  should  be 
limited  to  obtaining  the  input  data  and  to  examining  and  possibly  influencing  the 
outputs  ot  computerized  algorithms  as  specified  below  in  items  <2l  and  (3 1. 

<2t  The  process  designer  should  be  teserved  an  option  to  influence,  through  his  input 
data,  or  override  the  results  obtained  with  computerized  algorithms.  I- sample  the 
designer  should  be  able  to  specify  as  input  to  the  hardware  resource  assignment 
algorithm  the  minimum  number  ot  Processing  Mements  to  be  present  in  the 
hardware  configuration  and  the  PI-  residences  lor  a sunset  ot  process  programs. 

1 3t  The  designer  should  be  left  in  all  decision-making  nodes  with  more  than  one 
outgoing  branch  of  the  network  representing  the  overall  process  construction 
procedure:  i.e..  he  must  be  able  to  reject  or  accept  partial  or  complete  outputs  ot 
process  construction  and  to  determine  its  further  course  by  deciding  whether  to 
proceed  or  to  reiterate  a part  of  the  procedure. 

With  regard  to  the  automation  of  process  construction  as  the  man-machine  system, 
recommendations  are  stated  in  the  order  of  priorities  for  various  system  features  (which  also 
approximately  corresponds  to  the  order  of  their  increasing  cost): 

1 1 ) Integrate  the  programs  constituting  the  oveiall  process  construction  procedure  into  a 
system  by  providing  facilities  lor  sharing  the  model  data  between  individud 
programs  (this  recommendation  leads  to  the  requirement  to  develop  a suppoitiiig 
computer-based  information  system  as  a part  of  the  process  constructor.,  the  design 
requirements  tor  which  are  stated  in  Section  U.l 

<2)  Provide  programs  subroutines  which  would  genet  ate  punted  reports  on  intermediate 
outputs  ol  process  construction  at  all  designer's  decision  points. 

f.'i  Provide  programs  subroutines  which  would  document  the  process  in  the  torm  ot 
la  1 printed  reports  or 

1 b|  the  data  to  be  stored  and  preserved  in  the  libraries  >>|  l)P  M Process  Develop- 
ment Information  System,  which  has  been  referred  to  in  item  <!>  above,  the 
preserved  model  data  should  be  organized  and  loimatted  to  be  diiecllv  usable 
as  input  for  simulation  or  tor  execution  .<>1  the  pun  css  on  the  t.uect  DP  M 
System. 
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(4)  Ixtcinl  the  language  translator  which  will  be  used  to  compile  applications  (i.e., 
mission-oriented ) programs.  01  just  the  models  of  such  programs,  to  extract  and 
generate  input  descriptions  of'  individual  process  modules  lor  the  process 
construction  procedure  ( the  purpose  here  is  to  niimim/e  the  amount  of  manual 
work  needed  h generate  the  haste  inputs  lor  process  const! uction). 

(51  I Mend  the  DP  M Process  Development  Information  System  to  include  the  capability 
to  retrieve  and  reconfigure  the  information  on  model  data  stored  in  the  libraries. 

((»)  Provide  interactive,  on-line  remote  terminals  with  te-  ditmg  capabilities  (including 
all  support  software  hardware!  tor  interlacing  the  designer  with  the  process 
constructor  and  other  portions  <*t  the  DP  M process  development  system. 

Note  that  all  these  six  features,  to  he  added  incrementally,  imply  the  availability  of  the  DP'M 
Process  Development  Information  System  Such  a system  could  he  built  gradually  in  parallel  with 
the  rest  ot  functional  process  construction  capabilities.  Features  (I ) through  t.D  are  sufficiently 
modest  in  cost  to  he  implementahle  in  the  initial  version  ot  process  constructor  Addition  of 
feature  Mil  presents  the  transfer  from  the  initial  noninteractive-terminal  access  mode  to  an 
interactive  interlace  between  the  designer  and  the  computerized  portion  of  process  constructor, 
and  probably  repiesents  the  greatest  single  cost  increment  In  item  (4 1 above,  it  is  assumed  that 
the  translator  of  an  existing  language  is  moderately  extended.  If  a more  radical  approach, 
involving  the  development  ol  a special  language  and  its  translator  is  considered,  it  may  become 
the  most  expensive  and  time-requiring  single  item. 

4.  Recommended  Approach  for  the  Development  of 

frocevs  Construction  Capabilities 

Technically,  several  different  levels  of  process  construction  capabilities  are  feasible.  Each  is 
characterized  by  the  extent  ot  its  process  construction  functions,  the  level  of  automation,  and 
the  amount  ot  supporting  sottware  and  hardware  that  it  may  require.  Furthermore,  each  level  is 
characterized  by  the  J-gree  ot  the  process  construction  completeness  that  it  can  offer  and  so  by 
its  practical  use! illness.  At  one  extreme,  tor  example,  one  may  consider  limited  process 
construction  facilities  wl  icli  would  enable  the  proven  designer  to  construct  DP  M process  models 
for  simulation  and  whose  use  would  require  a great  amount  ot  manual  effort.  At  the  other 
extreme,  there  is  a full-scale  process  constructor  lor  the  development  and  maintenance  of  the 
real-time  processes  which  are  to  be  put  into  the  operational  aircraft.  To  be  at  all  useful,  the 
process  constructor  lor  the  last  case  may  require  extensive  hardware  and  software  support, 
several  years  may  be  needed  to  develop  it  and  its  full-scale  development  m3V  involve  a high 
degree  of  ’-sk.  I he  purpose  of  this  subsection  is  to  formulate  an  incremental  approach  for 
building  up  DP'M  process  construction  capabilities  which  would  promise  limited  but  practically 
useful  process  construction  capabilities  it  low  cost  Jtul  at  an  early  time.  This  approach  is  low 
risk  because  the  key  algorithms  jnd  procedures  needed  in  the  initial  process  constructor  arc  well 
understood  presently,  lor  they  have  been  mvestieated  am!  tested  in  the  course  of  the  work  being 
reported  herein. 

Analysis  ol  the  technical,  economic,  and  tune  (actors  involved  has  led  to  the  formulation 
of  an  incremental,  multi-step  approach  tor  building  up  DP’M  process  construction  capabilities. 
According  to  this  approach,  full-scale  process  construction  capabilities  should  be  built  up 
gradually  in  at  least  three  incremental  steps,  the  cud  product  of  each  step  should  constitute  a 
practically  useful  process  constructor  which  would  form  a nucleus  for  the  process  constructor  of 
the  next  step.  Next,  we  characterize  the  process  constructors  to  be  developed  in  each  of  the 
three  presently  identified  maior  steps 
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STI  P ! tidiii  Process  ( ointriii  tor  whose  capabilities  arc  to  be  limited  to  construc- 
tion of  DP  M process  models  lor  simulation  on  a host  developmental 
computer 

STEP  2 Intermediate  Pn>t,\\  t nnstnu  tor.  winch  would  he  used  in  a controlled 
laboratory  environment  to  construct  (at  process  models  for  simulation  and 
(hi  the  actual  soltwaic  pioiess  for  a target  DP/M  computer  network. 

SEEP  3 Printout  tun  (or  Ik'/riormcnt)  Prut  css  ( \ in  strut  tor  which  would  be  applied 
in  a typical  software  production  and  maintenance  environment  to  facilitate 
(a > development  of  the  DP/M  real-time  software  processes  which  are  to  be 
used  by  tlie  operational  aircraft,  and  <b>  maintenance  and  modifications  of  the 
processes  that  had  already  been  operationally  deployed. 

As  stated  earlier,  the  Intermediate  Process  Constructor  is  to  have  all  the  capabilities  of  the  initial 
Basic  Process  Constructor:  the  Production  Process  Constructor  is  to  have  all  the  caj  abilities  of 
the  Intermediate  Process  Constructor.  Nest,  each  above  identified  process  constructor  is 
discussed  separately  in  more  detail. 


The  reasons  for  starting  to  build  up  DP  M process  construction  capabilities  with  the 
development  of  Basic  Process  Constructor  arc  to: 

Test  and  evaluate  the  technical  approach  to  DP  M process  construction,  such  as  the 
practical  value  and  correctness  ot  key  algorithms. 

Test  and  evaluate  the  system  design,  such  as  the  “goodness'*  of  the  overall  process 
construction  procedure,  its  interface  with  the  user,  and  its  inputs  and  outputs. 

Obtain  initial  process  construction  capabilities  tor  process  development  based  on 
successive  simulations  at  the  earliest  time  possible. 


a.  Basic  Process  C onstroctor 

As  noted  previously,  the  mam  algorithms  and  procedures  of  the  baste  process  have  been 
investigated,  practically  implemented,  and  evaluated  in  the  course  of  the  work  which  is  being 
reported  here.  The  conclusions  that  have  been  drawn  from  that  work  indicate  that  the  technical 
problems  related  to  the  development  of  the  Basic  Processor  Constructor  are  well  understood  and 
that  such  a development  would  be  a low -cost  and  low-risk  ettort 

Subsection  IX  C contains  a summary  of  requirements  for  the  development  ot  the  Basic 
Processor  Constructor.  These  requirements  basically  can  be  divided  into  those  which  specify 
process  construction  algorithms  and  those  which  are  concerned  with  system  design  consider- 
ations. The  analysis  ol  process  construction  algorithms  is  discussed  in  the  next  subsection 
(Subsection  IX-B.Sk  As  implied  in  the  disunion  ot  requirements  and  algorithms,  the  Basic 
Process  Constructor  is  to  be  highly  automated  from  the  algorithmic  viewpoint,  yet  is  automated 
very  little  from  the  system  and  the  mleractior-vvith-the-uscr  viewpoints.  i.e.:.  it  is  to  be  only  an 
independent  set  ol  computer  programs  which  will  intercommunicate  through  shared  data  files 
and  which  use  will  interface  through  punched  input  cards  and  provided  output  reports. 

h.  Intermediate  Process  Constructor 


The  Intermediate  Process  Constructor  t discussed  next  The  main  puiposc  ol  developing 
this  system  is  to 


lest  .nut  evaluate  in  .1  lahotaloiy  environment  (hi-  alconthms  ami  system  design 
aspects  to  he  ttseii  in  the  thin!  \ vision  of  piocvss  i oust  rhetor 

Provide  practical  tools  lor  constructing  not  only  the  simulation  models  hut  also  the 
actual  sollvvato  pi  nc  esses.  the  latter  are  to  he  constructed  for  high  fidelity 
exeicises.  such  as  the  test  hed  simulations  in  which  the  actual  1)1*  N1  hardware 
would  he  used 

As  noted  previously,  the  Intermediate  Pioc ess  Constructor  shall  possess  all  functional  capabilities 
ot  the  Basic  Process  Constructor  and.  in  addition,  shall  he  capable  of  constructing  actual 
software  processes  lor  the  target  computer.  I'uithermoie.  the  Intermediate  Process  Constiuctor 
should  not  d tiler  much  trom  its  successor,  the  Pioduction  Process  Constructor,  in  the  process 
construction  algorithms,  it  may  differ  fiom  the  Production  Process  Constructor  in  its  system 
facilities,  reliability,  and  efficiency.-  Since  the  Inteimediate  Process  Constructor  is  primarily  to  be 
used  as  a test  bed  tor  algorithms  and  system  design,  it  would  be  economically  wise  to  provide 
this  process  constructor  with  an  elaborate  and  possibly  expensive,  user-system  interlace:  such  as. 
a net  work  ot  inteiactive  terminals,  each  with  input,  output,  and  exit  capabilities.  Some  ot  these 
automation  teatuies  are  to  be  introduced  in  the  Intermediate  Process  Constructor  in  order  to 
evaluate  them  tor  their  future'  use  in  the  Production  Process  ( onstructor 

c.  Production  Process  Constructor 

As  stateil  earlier,  the  Production  Process  Constructor  represents  the  end  product  ot  the 
process  construction  capability  development  cycle.  Its  mam  use  will  be  construction  and 
updating  ot  processes  for  the  actual  field  use.  Hence,  the  mam  design  requirements  are: 

The  ease  and  simplicity  of  use 

High  real-time  efficiency,  reprogrammaiulity . and  robustness  ot  the  end  product 
I operational  real-time  process! 

l-tficicney  ot  the  process  construction  procedure. 

As  noted  earlier,  the  Production  Process  Constructor  algorithmically  should  not  differ  much  from 
the  Intermediate  Process  Constructor,  but  it  may  diller  from  its  predecessor  in  the  level  of 
automation  ol  the  process  construction  procedure. 

do  satistv  the  first  requirement  stated  above  (the  ease  and  simplicity  of  use!,  the 
Production  Process  Constructor  shall  be  accessible  through  remote-interactive  terminals.  These 
terminals  shall  be  capable  ot  suppoiting  the  following  system  access  and  usage  (unctions. 

Inputting  ol  process  model  and  control  data 

f ditmg  ol  data  already  stored  in  the  system 

fontrolling  the  process  construction  procedure,  overruling  the  process  design 
decisions  made  by  computerized  algorithms 

Displaying  ot  intermediate  and  final  outputs 

Retrieval  ol  the  mtormatiou  on  the  process  stored  in  syMcin  libraries. 

The  requirement  lor  an  efficient.-  reliable,  and  lobust  end  product  (deployable  process 
stilt  ware)  is  very  critical  because  it  allects  not  only  the  shape  of  rc.-l-timc  software  but  also  the 
resulting  hardware  configuration.  I he  requirement  for  real-time  clfn  icney  in  process  execution 
implies  the  absence  of  bottlenecks,  delays,  or  missed  deadlines  that  may  affect  the  mission 
performance  The  process  is  robust  to  modifications  it  small  changes  in  the  process  software  or 
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control  cause  only  locali/cd  reconstruction  proNems:  i.e..  such  small  changes  do  not  ripple 
through  the  entire  process  construction  procedure  and  especially  do  not  affect  the  originally 
made  resource  allocation  assignments  (and  at  the  same  time,  the  hardware  configuration).  Level 
of  programmability  can  be  defined  as  the  cost  of  extending  the  software  per  one  unit  of 
addition.  Programmability  is  an  important  economic  factor  in  development  of  large-scale  real- 
time  systems  d".  to  the  high  cost  of  software  relative  to  that  of  hardware  (reference  (4)|;  it  is 
also  important  because  it  often  deteunines  the  critical  time  in-system  development. 
Reprogrammability  of  an  already  operational  software  process  is  important  for  similar  reasons. 

Both  the  process  robustness  relative  to  modifications  and  its  (re (programmability  are 
associated  with  the  level  of  hardware  resource  loading  or  saturation.  It  is  well  known  that  heavy 
loading  levels  make  software  difficult  to  (rc)program.  For  example,  if  the  memory  is  nearly 
exhausted,  even  the  smallest  perturbation  in  the  code  may  result  in  a big  reprogramming  effort. 
Furthermore,  relative  saturation  of  hardware  resources  has  a negative  effect  on  the  robustness  of 
process.  For  example,  doubling  the  scheduling  rate  of  a program  may  <-aus»>  exceeding  the 
processing  capacity  of  the  Pfc  to  which  the  program  had  been  originally  assigned  during  process 
construction;  implications  ot  exceeding  PE  processing  capacity  are  that  the  software  process  and 
possibly  the  hardware  will  have  to  be  reconfigured  in  order  to  accommodate  such  an  increase  in 
the  running  rate  of  a program.  In  view  of  the  above  considerations,  the  process  constructor  must 
be  capable  of  assigning  hardware  resources  in  the  way  that  will  maximize  hardware  load 
balancing  (equalization)  and  avoid  local  and  global  hardware  saturations.  Thus,  the  second  design 
requirement  can  be  reworded  as  follows:  The  process  constructor  shall  preserve  a high  real-time 
efficiency  of  the  process  (which  also  depends  on  the  design  of  the  Executive  and  of  the 
individual  programs)  and  properly  match  hardware  to  software. 
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By  the  eficiency  of  process  construction  procedure,  we  mean  relative  amounts  of 
computer  and  human  time  required  to  do  the  job.  Computer  efficiency  should  be  a lower 
priority  requirement  than  are  the  other  two  requirements.  In  fact,  it  may  conflict  with  the  other 
two.  What  can  bo  done  in  such  a situation  is  fixing  the  acceptable  performance  levels  with  regard 
to  the  first  two  requirements  and  making  the  computerized  process  construction  procedure  as 
efficient  as  possible.  On  the  other  hand,  human  efficiency  should  be  retained  as  a high  priority 
requirement,  for  one  of  the  fundamantal  goals  of  process  construction  is  to  eliminate  or 
minimize  the  manual  work  involved. 


5.  Analysis  of  Process  Construction  Algorithms 


This  section  has  a twofold  purpose:  ( 1 1 to  discuss  the  Basic  Process  Constructor  algorithms 
and  procedures  for  which  the  requirements  are  specified  in  Subsection  IX.C,  and  (2)  to  define  a 
precise  mathematical  model  fin-  the  problem  of  optimal  allocation  of  hardware  resources  and 
then  to  discuss  various  approaches  for  solving  this  problem. 


Algorithms  of  three  basic  types  come  up  in  process  construction: 

Process  Analysis  Algorithms  these  are  the  algorithms  that  are  used  to  analyze 
certain  aspects  oi  orocess  design  or  structure  for  evaluation  purposes. 


4 Ramamoorthy,  C.V.,  R.C.  Cheung,  and  K.H.  Kim:  "k 'liability  and  Integrity  of  Large  Computer  Programs."' 
Memorandum  So  ERl-M4.it)  (March  1974),  Electronics  Research  Laboratory,  College  of  Engineering.  University  of 
California,  Berkley.  California. 
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Fxamplc:  the  algorithm  used  to  anal  we  the  structural  correctness  ot  program 
graph  I Step  4 of  the  process  construction  procedure!,  where  a graph  is  said  to 
he  structurally  correct  if  it  contains  precisely  one  entry  node,  precisely  one 
exit  node,  and  no  loops  through  its  nodes. 

Pioccss  Design  Algorithms  they  affect  the  overall  structure  and  design  ol  the 
process.  Fxamplc:  the  algorithm  used  to  allocate  DP  S!  Processing  hlemcnts  to 
process  programs  (Step  0 of  the  Process  Construction  Procedure) 

Data  franstormation  Algorithms  these  are  used  to  reduce  or  restructure  model  data 
and  to  pel  form  tormat  or  value  translormations  on  the  data,  {-sample: 
generation  of  control  data  for  process  simulators  (Steps  7.  8.  and  9 of  the 
process  construction  procedure). 

Note  that  the  above  given  charac  .cri/ation  of  algorithms  is  not  a classification  in  the  sense  that  it 
is  neither  mutually  exclusive  n«<r  all  inclusive.  There  are  algorithms  in  the  process  construction 
procedure  which  have  the  clta'acteristics  ol  all  three  types.  For  example,  the  first  step  of  process 
construction  procedure  is  represented  by  an  algorithm,  called  Computer-Independent  Model 
Generator,  which  analyzes  the  data  to  identify  all  input-output  relations  between  the  tasks  of  a 
program,  constructs  the  maximally  parallel  predecessor-successor  graph  for  each  modeled  program 
m the  process  (which  is  a design  task),  and  performs  various  transformations  on  the  input  data  in 
order  to  reorganize  and  compact  it  foi  future  use. 

a.  Provens  Analysis  Algorithms 

Several  piocess  analysis  algorithms  come  up  in  the  early  phase  of  process  construction 
(Subsection  IX.Ci  These  algorithms  are  mainly  used  to  analyze  the  structure  of  the  process  and 
to  determine  the  input-output  precedence  relations  in  individual  programs.  All  process  analysis 
algorithms  can  be  cost-effectively  computerized.  Since  such  algorithms  are  not  used  for  design 
decision  making,  there  is  no  need  to  put  the  process  designer  into  the  loop  to  examine  and 
possibly  nerrule  their  outputs.  Hence,  the  interaction  between  the  computerized  process  analysis 
algorithms  and  the  designer  normally  can  be  limited  to  the  examination  of  the  final  output  data. 

The  following  process  analysis  algorithms  were  implemented  and  computationally  tested  in 
the  course  of  the  Process  Construction  Case  Study  (reference  n>i. 

Topological  Sort 

Path  Matrix  Construe toi 

I xeciition  Path  Generator 

They  constitute  the  key  algorithms  ol  Slept*  ol  process  construction  procedure  (Subsection 
IX.Ci  Since  the  above  three  algorithms  are  to  be  used  in  the  Basic  Process  Constructor,  they  are 
described  next  in  more  detail.  The  lollowmg  should  be  noted  before  stalling  their  discussion: 

(li  In  the  l.xperimental  Process  Constmction  System  of  the  case  study  they  have  been 
embedded  m a single  computet  progiam  (which  corresponds  to  the  Process  Analysis 
Program  ol  Step  G in  the  procedure  discussed  in  Subsection  IX.C)  and  are  executed 
in  the  same  older  as  listed  above 


( omulvci  (t.A..  et  a!.:  iHsinhimJ  fr'iiioi-  l/ntum  .In hnvi inr<  \.  Iniermi-leclniic.il  Report  for  CSAF 
Avionic*  laboi.iloiy  fecac  liiMiul'tciilc  liuoipor.iie.l.  Itali.i-.,  lexas.  Septcnibei  I ‘*7-4. 


(2)  For  analysis.  the  process  is  decomposed  into  programs  and  a single  progrant  is 
processed  at  a time. 

(3 ) Assume  for  the  following  discussion,  that  the  process  program  to  be  analyzed 
consists  of  N tasks,  which  will  he  referred  to  as  N nodes.  The  following  items 
describing  a process  program  comprise  the  basic  input  to  the  three  algorithms: 

(a)  The  overall  description  of  the  program  which  consists  of  program  ID, 
expected  iteration  (repetition!  rate  in  real  time,  node  (task)  count,  the  IDs  of 
the  external  and  interprogram  inputs  and  outputs  to  he  handled  by  the 
program,  and  the  ID  of  the  entry  node. 

(h)  Description  of  each  node  (task),  consisting  of  the  node  ID,  minimum  and 
maximum  run  times,  permanent  and  temporary  storage  requirements,  the  IDs 
of  all  immediate  successor  nodes  and  probabilities  of  transitioning  to  them,  a 
list  of  standard  subroutines  called,  and  the  IDs  of  all  intraprogram-intertask 
inputs  and  outputs  associated  with  the  task. 

(4)  One  of  the  first  steps  in  program  analysis  is  to  construct  from  the  input  information 
two  fundamental  matrices  which  are  to  be  used  in  all  three  algorithms: 

(a)  N X N transition  probability  matrix  T,  the  (U)th  element  of  which  specifies 
the  probability,  . for  a direct  transition  at  execution  time  from  node  I to 
node  J.  If  direct  transition  from  node  1 to  node  J is  impossible,  then  Py  = 0: 
note  that  P, , + P,  , . . . P1Ni  = I is  true  for  each  row  of  matrix  T except  the 
one  whir'  ..  resents  the  program  exit  node-for  that  row.  the  probability 
sum  is  0 

(b)  N X N node  adjacent  matrix  A,  the  (I.J)th  element  of  which 

A(I.J)  = 1 if  tliere  is  a direct  link  from  node  I to 
node  J.  which  exists  if  and  only  if 
T(I,J)=P, , >0 
= 0 otherwise. 

A description  of  the  three  algorithms  follows. 

( i ) Algorithm  I ' Topological  Sort 

This  algorithm  analyzes  the  input-output  precedence  relations  between  the  nodes  (tasks)  of 
a program  model  and  generates  topologically  ordered  node  ID  numbers  which  are  internally 
needed  thro  igliout  the  program  analysis  phase  of  process  construction. 

A program  is  topologically  sorted  (or  its  nodes  are  ordered)  if,  for  any  two  nodes  with  ID 
number?  I and  J,  I < J implies  that  the  Jth  node  is  not  an  immediate  or  remote  predecessor  of 
the  1th  node. 

The  topological  sort  algorithm  is  discussed  in  references  |<>  | and  |7|.  The  version 
•mpiemented  in  the  process  construction  case  study  follows  reference  |t*|.  in  which  the 
algorithm  is  referred  to  as  Fulkerson's  rule.  It  uses  the  following  terminology 


6 Berziiss.  A.T.:  Pula  Structures;  Theory  and  Trainee.  Academic  Press,  Inc..  New  York.  I ‘>71. 

’ Knuth.  I)£:  The  Art  <>]  Commuting  Programming.  Vol.  t (Second  t-.dilion).  Addison-Weslcy  Publishing  Co- 
Reading.  Mass-  I ‘<73. 
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< I ) Digraph  a directed  grm'i 

(2)  It  ulu  Digraph  a directed  graph  with  no  closed  loops  i cycles)  through  its  nodes 

(3)  Indegree  uf  a nude  (or  uf  a set  uf  nudes)  X is  the  number  of  arcs  coming  into  X 

from  the  nodes  of  the  digraph  (1  that  are  in  the  complement  of  X with  respect  to 

C. 

<4)  Out  degree  uf  a nude  fur  uf  a set  <>f  nudes)  X is  the  number  of  jns  emanating  from 

X and  pointing  to  the  nodes  in  the  complement  of  X 

(2)  Fulkerson's  Rule 

Let  X be  the  set  ol  nodes  that  have  been  numbered  (i.e  . given  topologically  ordered  IDs) 
at  any  particular  stage  in  the  application  ol  the  algorithm  to  an  acyclic  digraph  Proceed  as 
follows. 

I Set  I = I 

2.  If  there  is  no  unnumbered  node  with  zero  indegree,  go  to  5.  otherwise,  go  to  3- 

3.  Assign  the  number  I to  an  unnumbered  node  with  zero  tndegree  as  its  new 

(topologically  ordered)  ID. 

4.  Set  I = t + I : go  to  2. 

5.  If  all  nodes  have  been  numbered  (i.e..  assigned  topologically  ordered  IDs),  restore  all 
removed  arcs  and  stop:  otherwise,  go  to  6. 

6.  If  the  outdegree  of  X is  not  0.  remove  all  arcs  originating  from  X and  go  fo  2. 

(3)  Algorithm  2:  Path  Matrix  Constructor 

This  algorithm  analyzes  the  adjacency  matrix  of  the  program  graph  to  construct  »he  path 
matrix  P.  whose  (I.J)th  element, 

Pt  I.J)  = 1 if  there  exists  at  least  one  path  from 
node  I to  node  J 

= 0 otherwise. 

Note  that  the  existence  of  a path  does  not  imply  the  existence  of  an  arc  directly  linking  1 to  J.  a 
path  from  I to  J may  traverse  several  nodes. 

The  implementation  of  the  Path  Matrix  ('.  nstructor  in  the  process  construction  study 
follows  a very  efficient  procedure  credited  to  S a Warchall.  which  ir  discussed  in  reference  |6|. 
For  convenience,  it  has  been  included  in  the  sequel. 

(4)  Warciiall's  Algorithm 

Given  an  N X N X m:*tnx  with  elements 

X,3  = 0 or  1. 


Pr«n.c«l  as  tollows 

I Set  V = X 
: Set  J = 1 

3 Set  I = I 

4 It  X*,,  ~ 1.  then  set  X*,k  = X,k  VXtk  lor  jII  K troni  I to  N 

*<  Set  1 = i + I If  I < N.  then  go  to  4 otherwise  continue 

6 Set  J = J ♦ I If  J <.  N.  thet.  go  to  3 else  stop 

According  to  W'archall’s  theorem  [ret  (61.  p 206).  it  X is  the  adjacency  matrix  ot  a directed 
graph  Ci.  the  matrix  X*  generated  In  the  abuse  algorithm  is  the  path  matrix  ot  (»  li  Step  4 
above,  the  Boolean  disjunction  Operator  "V"  is  defined  as  tollows  0 s 0 = 0 0 s I = 1 s 0 = I 
v I = I 


Both  the  path  matrix  and  the  node  adjacency  matrix  are  used  to  analyze  the  following 
aspects  of  the  correctness  ot  program  structure 

Atnence  ot  loops  in  the  program  graph 

Whether  the  designated  entry  node  actually  has  no  predecessors  and  whether  there 
are  no  more  nodes  without  predecessors 

Whether  the  designated  exit  ( terminal > node  actually  has  no  successors  and  whether 
there  are  no  more  nodes  without  successors 

(5)  Algor.ihm  3.  Execution  Path  Generator 

Assume  that  the  program  under  analysis  contains  N nodes  (tasks).  This  algorithm  analyzes 
the  N X N node  adjacency  matrix  A ot  tl.c  program  to  construct  all  alternative  execution  paths 
through  the  program,  each  starting  at  the  entry  node  and  ending  at  the  exit  node.  If  there  is  an 
execution  path  of  length  K throi  < h the  nodes  M,  . M,  , . . . (where  M,,  is  the  program 
entry  mode  M.  . the  exit  noi  Mv  ).  the  constructed  list.  M,  — M,  -*  — M,k,  delines 

it.  The  Execution  Path  (jenerator  can  be  considered  as  being  a procedure  tor  constructing  the 
program  graph  from  the  input-output  relations  between  individual  pairs  of  nodes,  specified  by 
the  node  adjacency  matrix.  A.  Recall  that  the  (l.J)th  element  of  matrix  A is 

A(I.J)  = I if  node  I produces  outputs  which  are 
consumed  by  node  J 

= 0 otherwise. 

The  rows  (and  columns)  of  A are  assumc*d  to  be  ordered  by  the  increasing  values  of  the  node 
topological  ID  numbers. 

The  implementation  of  Execution  Path  Generator  algorithm  n the  Process  Construction 
Case  Study  [reference  ( 5 ) j is  based  on  the  following  principles: 

Start  at  the  entry  node  to  initialize  a path  for  each  outgoing  arc  (branch  successor), 
add  the  ID  number  of  the  successor  for  each  initialized  path. 


Proceed  from  node  J-I  to  node  J lor  equivalently  from  the  i J-l  hh  to  the  Jth  row  of 
the  node  adjacency  Matrix  A),  where  the  node  II)  numbers  correspond  to  the 
topological  ordering  ot  nodes  constructed  by  Algorithm  I 

If  the  Jth  row  of  A represents  the  last  (terminal)  node  in  an  already  partially 
completed  path,  extend  this  path  by  adding  to  it  the  node  II)  number  k 
which  corresponds  to  the  leftmost  nonzero  entry  in  the  Jth  row  of  A ihen 
continue  to  the  right  in  (he  same  row  of  A and.  for  each  newl>  encountered 
nonzero  entry,  e.g..  A(J.L).  create  a new  path  by 

Copying  the  first  (leftmost)  path  that  was  extended  in  row  J 

Deleting  trom  it  the  lastly  added  . >de  (whose  11)  number  is  k) 

Adding  to  it  the  node  II)  number  corresponding  to  the  Lth  column 

Stop  after  processing  the  (N-l  )th  row  of  A (the  last  row  represents  the  exit  node) 

Computer  implementation  of  this  algorithm  is  greatly  simplified  if  list  processing  facilities 
are  available  to  the  programmer,  for  the  number  of  paths  to  be  newly  added  or  lists  if  each  list 
represents  a path  tends  to  increase  as  one  progressively  steps  through  the  rows  of  the  adjacency 
matrix  A. 

b.  Process  Analysis  Program 

In  the  Process  Construction  Case  Study,  algorithms  1.  2.  and  3 constitute  parts  of  a bigger 
program,  called  the  Process  Analysis  Program.  Since  the  Process  Analysis  Program  has  been  found 
to  be  a useful  tool  for  analyzing  process  decomposition  into  programs  (i.e..  to  determine  whether 
no  program  exceeds  the  capacity  of  a single  DP/M  Processing  F.lement)  and  since  a program 
similar  to  it  has  been  specified  at  Step  4 in  the  process  construction  procedure  of  the  Basic 
Process  Constructor  (Subsection  IX.C).  it  is  outlined  below. 

The  Process  Analysis  Program  represents  a multi-step  procedure  consisting  of  the  following 
main  steps. 

1.  Read  the  input  description  of  a program  and.  using  Algorithm  1.  generate  the 
topologically  ordered  node  (task)  II)  numbers. 

2.  Generate  the  node  adjacency  matrix  A and  the  branch  transition  probability  matrix 
T (in  both  matrices,  rows  and  columns  must  be  ordered  by  the  increasing  values  of 
the  topological  ID  numbers:  i.e..  if  1 is  such  a number,  then  the  node  which  is 
represented  by  ! must  correspond  to  the  lth  row  or  column  of  matrices  A and  T) 

3.  Using  Algorithm  2,  generate  the  path  matrix.  P. 

4.  Analyze  the  structural  correctness  of  the  program  under  analysis:  print  a report  on 
results  of  this  analysis. 

5.  Apply  Algorithm  3 to  construct  all  alternative  execution  paths  througn  the  progi  " 

6.  For  each  path,  compute  its  execution  probability  and  projected  execution  timing. 

7.  By  considering  the  specified  iteration  rate  of  the  program,  compute  the  loading  of 
*He  processor  timeline  in  real  time  by  the  program;  compute  the  permanent  and 

. .nporury  storage  required  by  the  program. 

iTint  a report  summarizing  the  results  of  preceding  steps. 


8. 


To  illustrate  the  above  procedure,  the  output  reports  produced  by  the  present 
implementation  of  the  Process  Analysis  Prolan:  are  shown  in  Figures  164  through  1 70.  Two 
basic  reports.  Program  Analysis  Report  (Figures  164  through  168)  and  Program  (Synthetic) 
Model  Report,  are  included.  Note  that  these  reports  are  similar  to  those  to  be  produced  in 
Step  4 of  the  process  construction  procedure  which  is  described  in  Subsection  I.X.C. 

The  function  of  Program  Analysis  Report  is  to  provide  the  process  designer  with  the 
information  which  will  enable  him  to  decide  whether  the  program  satisfies  all  structural 
requirements  This  report  consists  of  five  pages.  The  first  page  (Figure  164)  contains  a summary 
of  the  input  information  which  describes  the  program  under  consideration.  The  last  page 
(Figure  168)  shows  the  results  of  the  structural  analysis  of  the  program.  In  the  particular  case 
shown,  the  program  whose  name  is  NARBSWD  has  been  found  to  be  structurally  correct 

The  second  report  (Figures  169  and  170)  summarizes  the  synthetic  model  o)  the  program. 
Its  function  is  to  provide  the  proven  designer  with  the  information  needed  to  decide  whether  the 
program  in  question  can  be  run  on  a single  Processing  Flement.  If  the  answer  is  yes  for  all 
programs  in  the  process  model,  we  say  that  it  is  properly  decomposed. 

c Optimal  Allocation  of  Hardware  Resources  to  Process  Components 

This  subsection  formulates  a mathematical  optimization  model  for  the  hardware  resource 
allocation  problem  and  then  examines  alternative  approaches  for  solving  it.  We  start  with  a 
background  review,  state  a few  assumptions  to  establish  firm  working  rules,  and  then  proceed 
with  the  problem  statement.  Next,  we  suggest  several  alternative  algorithms  for  solving  this 
problem. 

The  function  of  the  Hardware  Resource  Allocation  .Algorithm  is  to  allocate  hardware 
resources  (i.e.,  the  DP/M  Processing  Elements)  to  process  programs.  This  assignment  is  to  be 
optimal  in  the  sense  that  it  is  to  minimize  the  resulting  data  bus  traffic,  which  also  amounts  to 
minimizing  the  number  of  Processing  Elements  in  a DP/M  network.  Hence,  this  algorithm  can  be 
considered  as  beinf<  a procedure  for  determining  the  best  hardware  configuration  for  a given 
model  of  the  real-time  process.  Before  we  proceed  with  the  discussion  of  the  Hardware  Resource 
Allocation  Algorithm,  we  shall  elaborate  the  idea,  stated  at  the  end  of  the  preceding  paragraph, 
about  fitting  hardware  to  software  in  designing  real-time  systems.  In  the  traditional  approach  of 
real-time  system  development,  the  software  development  effort  has  to  wait  until  the  hardware  is 
selected  and  then  the  programs  are  written  under  hardware  constraints:  the  important 
consequence  of  this  approach  is  that  the  development  and  the  final  shape  of  mission-oriented 
algorithms  also  become  subject  to  hardware  constraints.  Although  this  approach  has  many 
disadvantages,  it  could  be  somewhat  justified  at  the  time  when  the  hardware  cost  was  the 
dominating  factor  in  computer  system  development  and  when  the  current  techniques  and  tools, 
such  as  simulation,  for  developing  real-time  software  on  a host  computer  were  not  available:  but 
the  situation  has  been  reversed  during  the  last  decade  by  a sharp  decrease  in  hardware  cost 
relative  to  that  of  software.  For  example  in  reference  (4 1 . the  cost  of  software  amounted  only 
about  to  25  percent  of  the  USAF  budget  for  electronic  data  processing  in  I960  (75  percent  went 
for  haidware),  while  in  1973  the  cost  of  software  amounted  to  approximately  80  percent  of  the 
USAF  budget  for  EDP.  According  to  the  reference  just  cited,  the  traditional  real-time  system 
development  philosophy  based  on  fitting  software  to  hardware  suffers  from  the  following 
disadvantages: 
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Figure  164.  Program  Amiyim  Repcn,  ?»§e  1 


Inability  to  start  thv  software  development  until  hardware  has  been  procured,  or  a' 
least  selected,  pushes  software  further  out  in  the  critical  path 

Since  hardware  selection  must  be  made  without  understanding  the  actual 
requirements  imposed  by  the  software  process,  selection  of  an  inadequate 
hardware  configuration  may  dramatically  affect  the  productivity  of  software 
development 

The  resulting  hardware  selection  is  poor  functionally  and  is  cost-ineffective. 

As  we  approach  about  85  percent  usage  of  processor  time  and  memory,  the  software  cost 
and  the  time  required  for  software  development  abruptly  curve  up  to  infinity.  Further,  the  cost 
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OP/M  PROCESS  CONSTRUCTION 


jATF:  750* *6 


PROGRAM  MAKE : 

ID  • : 

0  OF  ITERATIONS  PE«  SECONO: 


NARBSMf) 

0 

32 


0 Of  MOOES:  9 

IMPUTTEO  10  • OF  ENTRY  NOOE:  184 

COMPUTER  MODEL:  OP/M  PROTOTYPE 


TRANS  PROS  MATRIX  TPRfttfK 


2 


1 0.0000  0.2500  0.0000  0.0000  0.0000  0.7500  0.0300  0.0000 

a. oooo 

2 0.0000  0.0000  0. 5C  >0  0.5000  0.0000  0.0000  0.0000  0.0000 

0.0000 


3 O.OOCO  0.0000  0.0000  0.3000  1.0000  0.0000  0.0000  0.0000 

0.0000 

4 0.0000  0.0000  0.0000  0.0000  1.0300  0.0000  0.0000  0.0000 

0.0000 

5 0.0000  0.0000  0.0000  0.0000  3.'  J 1.0000  0.0030  0.0000 

0.0000 

6 0.0000  0.0000  0.0000  3.0000  0.0000  0.3000  1.0000  0.0000 

0.0000 

7 0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.3000  1.0000 

0.0000 

8 0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000 

1.0000 

9 0.3000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000 

0.0000 


Figure  I6S.  Piofim  Anafym  Report,  Page  2 
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l»R/M  PROCESS  CONSTRUCTION 
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• Of  ITERATIONS  REA  SECOWO:  32 
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Figure  166.  Program  Analyw  Report,  Page  3 
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DP/M  PROCESS  CONSTRUCTION  DATE r TSUI 16 
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Figure  167.  Program  Analysts  Report,  Page  4 
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DP/M  PROCESS  CONSTRUCTION 


DATE  5 T50l  16 


PROGRAM  NAME:  NARSSttO 

10  A:  0 

« Of  ITERATIONS  PER  SECOND:  32 

• OF  NOOES:  9 

INPUTTED  ID  • OF  ENTRY  NOOE : ISA 


COMPUTER  MODELS  OP/M  PROTOTYPE 

•*«•** »••*»*•«*•**• •»*****••«*•»••**••*»*•*•****»•*«•'**•*#••***•***•**•* 


INPUTTED  INFORMATION  : 
N * 9 

ITS  - I 

ITX  * 9 


RESULTS  OF  THE  TEST  ON  THE  CORRECTNESS  OF  GRAPH  STRUCTURE 


ALL  NODE  10  AS  ARE  TOPQIO  AS 


NO.  OF  CVCLtS 


0 (OK  IF  ZERO) 


10  OF  THE  STARTING  NOOE 

NO.  OF  NOOES  NONREACHABLE  FROM  ITS 

10  OF  THE  EXIT  NODE 

NO.  OF  NOOES  FROM  WHICH  THFRE  IS  NO  PATH  TO  ITX 


1 (OK  IF  * I TS) 

I <CX  IF  *1) 

9 (OK  IF  * ITX) 

l (OK  IF  =1) 


*********************************************************** A************ 


Figure  168.  Program  Analysis  Report.  Page  5 


to  maintain  and  modify  the  software  process  which  hardly  fits  a computer  is  economically 
prohibitive.  (It  is  ironic  that,  in  spite  of  what  just  ..as  been  said,  some  system  designers  continue 
to  be  proud  of  being  capable  of  tight  designs.)  With  decreasing  cost  of  hardware  and  with  rising 
cost  of  software,  getting  too  close  to  the  saturation  points  of  the  designs  must  by  all  means  be 
avoided.  This  consideration  must  be  kept  in  mind  in  order  to  prevent  the  misuse  of  the  Optimal 
Hardware  Resource  Allocation  Algorithm;  although  it  will  allow  matching  hardware  to  software, 
the  resulting  hardware  configuration  must  not  be  allowed  to  become  too  tight.  Actually,  the 
algorithm  must  be  designed  to  permit  its  user  to  specify  and  control  the  desired  level  of 
hardware  saturation. 
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Figure  169.  Program  Model  Report.  Page  l 


To  formulate  the  hardware  resource  allocation  problem  and  the  optimality  criterion  tor 
this  problem,  the  following  assumptions  ha\e  been  made. 

No  program  in  the  process  model  exceeds  the  specified  level  of  the  total  capacity  of 
a single  Ph  (As  the  process  construction  progresses  beyond  the  process 
decomposition  analysis,  we  are  guaranteed  that  this  will  be  the  case. I 

Selected  DP/M  Processing  Elements  may  have  to  be  preassigned  to  certain  programs, 
which  still  may  leave  enough  processing  capacity  in  these  PFs  to  assign  them 
also  to  other  programs. 

The  hardware  resource  allocation  algorithm  'o  be  discussed  in  the  sequel  must  be 
capable  of  being  applied  either  to  '.he  entire  process  or  to  tlu  individual 
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PP/M  PROCESS  CONSTRUCTION 


DATE:  TSOI  16 


PROGRAM  NAME:  NARBSWO 
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• OF  ITERATIONS  PER  SECOnO:  32 
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l * 96 3.0  l 86-  > 1 05-> 1 86-> 1 88-> 1 89-> 1 90-> 1 9 1-> 1 92 
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PERMANENT 

TEMPORARY 

««***•»*•*••  *•••*•**« 


3161  16—8  I T WORDS 
39  16-SIT  WORDS 


Figure  170.  Program  Model  Report,  Page  2 


components  of  the  process,  such  as  various  avionics  subfunctions  (The  latter 
option  may  be  needed  to  guarantee  a desired  number  of  distinct  Processing 
Element  Affinity  Groups  in  the  hardware  configuration.! 

The  second  assumption  has  been  made  to  guarantee  the  placemen  of  External  10  Handlers 
(programs  especially  designed  to  handle  the  external  I/O)  within  the  Processing  F.lements  which 
are  connected  with  appropriate  sensors  or  actuators.  It  can  also  be  used  to  guarantee  a desired 
minimum  number  of  Processing  Elements  in  the  entire  system  or  jusi  in  an  Affinity  Group  of 
Processing  Elements. 


The  hardware  resource  allocation  procedure  is  mainly  concerned  with  minimizing  the 
interprogram  bus  I/O  traffic;,  the  assignments  to  be  made  cannot  affect  the  intraprograni-'ntertask 
I/O  traffic  because  of  the  requirement  that  a program  always  be  mapped  into  a single  PE. 
However,  the  assignments  indirectly  affect  the  amount  of  bus  traffic  that  results  from  the 
external  I/O  due  to  communications  between  the  process  components  and  various  sensors  or 
actuators.  Recall  that  alt  external  I/O  is  to  be  channeled  through  special  external  I/O  handling 
programs,  already  referred  to  as  External  I/O  Handler  . which  must  be  placed  in  preassigned 
Processing  Elements,  i.e..  in  those  PEs  which  are  directly  connected  to  appropriate  sensors  or 
actuators.  To  other  programs  of  the  process,  an  External  I/O  Handler  looks  just  as  another 
program;  if  the  handler  is  communicating  with  a sensor,  it  may  produce  outputs  that  are 
consumed  by  the  avionics  programs  as  their  inputs;  furthermore,  these  communications  may  or 
may  not  cause  bus  traffic,  depending  on  the  locations  of  the  consumer  programs  relative  to  the 
sensor.  Similarly,  if  a handler  interfaces  with  an  actuator,  it  receives  inputs,  sent  to  it  by  various 
avionics  programs  as  their  outputs,  which  again  may  or  may  not  generate  bus  traffic.  Thus  v.e 
relative  locations  of  an  External  I/O  Handler  program  and  the  avionics  pro  trams  that 
communicate  with  the  former  determine  the  amount  of  the  resulting  bus  traffic.  The  Hardware 
Resource  Allocation  Algorithm  attempts  to  minimize  the  potential  traffic  by  coalescing  (within 
the  given  constraints)  heavily  intercommunicating  prog.ams  into  the  same  Processing  Elements. 


The  problem  of  ontimal  hardware  resource  allocation  for  DP/M  processes  can  be  stated  as 
follows: 

( 1 ) Let 

NP|.  = The  initial  number  of  PEs  in  the  system  (or  in  the 
Affinity  Group  under  consideration) 

Nt  = Number  of  programs 

T|  = The  processor  time  required  per  one  unit  of  real  time, 
such  as  I second,  by  the  1th  program 

S|  - The  amount  of  storage  needed  for  the  ith  program 

M|j  = Amount  of  LO  traffic  between  programs  1 and  J per 
one  unit  of  real  time. 

(2)  Consider  the  allocation  variables  XIK.  where 

XiK  = 1 if  the  Kth  PE  i»  allocated  for  program  1 
= 0 otherwise. 

(3)  It  will  be  convenient  to  introduce  vectors 

x,  = txll.X|).  . ,X1K....  x1Npi> 

Then  the  dot  product 

Xj  • Xj  = I if  tasks  I and  J arc  put  into  the  same  PE 
= 0 otherwise 


l Note  that  the  notation  used  above  neglects  to  denote  vector  transposes.) 


(4)  We  want  to  find  the  maximum  of 


NT  Nt 

o=yy  m„  <x,  • x,) 

subject  to  the  following  constraints  for  K = 1.2 NPt : 

nt 

^ ^ T|  X,K  <ET)  seconds 

i =l 

A 

nt 

y S,  XJK  < (Number  of  words  available  in  memory  of  Kth  PE  for  avionics 
jT|  programs)  X Es 

where  ET  and  Es  are  the  desired  upper  limits  on  the  processor  time  and  storage  saturation  levels, 
respectively;  clearly,  the  bounds.  0 < ET  < 1 and  0 <ES  < 1 . must  be  satisfied. 

The  following  remarks  apply: 

Performance  index  Q measures  t'-e  amount  of  bus  traffic  eliminated  by  making, 
within  the  stated  constraints,  the  most  heavily  intercommunicating  programs 
share  the  same  Processing  Elements. 

To  simplify  the  optimization  problem,  t ’e  amount  of  the  processor  time  gained  by 
eliminating  messages  from  the  bus  traffic  has  not  been  accounted  for  in  the 
constraints  on  processor  time:  the  effect  of  this  simplification  is  to  make  ’he 
constraints  slightly  pessimistic. 

Solving  this  problem  also  solves  the  problem  of  determining  the  minimum  number 
of  PEs  needed  for  the  considered  portion  of  process.  Initially,  set  NPJ.  ( = 
number  of  PEs)  large,  perhaps  equal  to  the  number  of  programs  in  the  model. 
The  obtained  optimal  values  for  the  assignment  variables.  XiK  will  show 
which  PEs  will  remain  unused:  these  PEs  should  be  eliminated  from  the 
hardware  configuration. 

Since  certain  programs  (expecially  External  I/O  Handlers)  must  be  mapped  into 
predetermined  PEs.  their  assignment  variables.  XtK  . ’re  a priori  known.  Thus, 
the  solution  of  the  optimization  problem  is  reducible  to  finding  optimal  values 
for  the  remaining  X!K  . which  in  the  literature  on  optimization  are  known  as 
free  variables,  in  contrast  to  the  a priori  set  or  fixed  variables. 

The  optimization  problem  as  stated  above  is  3 quadratic  integer  programming 
problem:  since 


Xj  • Xj  = 1 or  0 for  an\  I and  J 


this  program  is  reducible  to  a standard  linear  integer  programming  problem. 


Several  algorithms  Tor  solving  the  linear  integer  programming  problem  are  known  in 
literature  (references  (8)  and  (9)],  However,  these  algorithms  are  computationally  expensive 
and  typically  require  a large  amount  of  memory.  Therefore,  it  was  decided  to  look  into  faster 
but  suboptimal  heuristic  procedures.  A class  of  such  procedures  is  represented  by  what  is  known 
as  cluster  analysis  methods:  these  techniques  have  found  applications  in  many  fields  (such  as 
pattern  recognition,  information  retrieval,  etc.)  where  large  quantities  of  objects  are  grouped  by 
constructing  clusters,  each  containing  objects  interrelated  by  certain  criteria. 

In  our  case,  a cluster  represents  a group  of  urograms  that  heavily  intercommunicate  among 
themselves  and  relatively  little  with  the  programs  belonging  to  other  clusters.  Furthermore,  if  the 
time  and  memory  constraints  are  satisfied  by  a cluster  of  programs,  a single  PE  may  be 
associated  with  it.  At  the  start  of  a clustering  procedure,  all  External  I/O  Handlers  must  be 
preassigned  as  seeds  of  clusters  (depending  on  sensor  or  actuator  locations,  several  External  I/O 
Handlers  may  form  a single  seed).  In  addition,  other  (i.e..  non-I/O)  programs  may  be  designated 
as  cluster  seeds.  As  programs  are  assigned  to  or  transferred  between  already  established  clusters 
during  the  execution  of  a clustering  algorithm,  individual  clusters  may  exhaust  the  capacity  of 
the  DP/M  processing  elements:  several  options  exist  for  what  to  do  in  such  a situation.  One 
approach  is  to  proceed  without  paying  any  attention  to  the  constraint  violations  until  all 
programs  have  been  clustered:  thereafter,  split  each  violating  cluster  into  several  clusters.  Another 
strategy  is  to  create  new  clusters  just  before  a cc  nstraint  violation  occurs. 

To  apply  the  cluster  analysis  techniques  to  the  DP/M  hardware  resource  allocation 
problem,  the  mathematical  model  of  the  optimization  problem  outlined  above  must  be  expanded 
tr  include  the  measure  of  association  between  programs.  Many  different  measures  are  known  in 
technical  literature  ((10)  is  a good  first  reference):  furthermore,  each  measure  can  be  used  with 
many  different  clustering  procedures.  Selection  of  a proper  measure  and  of  suitable  measurement 
variables  is  important,  for  it  may  critically  affect  the  separability  of  programs  into  clusters. 

To  see  how  association  between  programs  can  be  measured  for  the  DP/M  haidware 
resource  allocation  problem,  consider  the  following  example,  which  illustrates  one  possible 
approach: 

Define  the  NTxNM  program-to-l/O  matrix  P,  where  NT  = number  of  programs  and 
Nm  = number  of  the  interprogrum  I/O  messages  (types  of  inputs/outputs)  in 
the  process  model,  as  follows: 


P(l,K)  = t MK 

= 0 


if  the  Ith  program  produces 
(or  consumes!  the  Kth  message 

otherwise 


'Edwards,  J "Hierarchul  Cunirol  in  Operating  Systems  for  Multiple  Computer  Systems."  Ph.D  thesis  (in 
preparation),  the  University  of  Oklahoma.  Norman.  Oklahoma 

’Garfmkel,  R.  S.,  and  G.  L Nemhauter:  “Integer  Programming."  John  Wiley  and  Sons.  Inc..  New  York,  1972. 

10  Andetberg,  M.  R.:  “Clutter  Analysis  for  Applications."  Academic  Press.  Inc..  New  York.  1973. 
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Here,  the  quantity  MK(X))  measures  the  bus  loading  per  unit  time  by  the  Kth 
message;  this  loading  is  proportional  tc  the  message  length  in  bits  and  to  the 
expected  transmission  rate. 

The  following  two  related  measures  of  association  between  two  programs  »r«* 
examined  in  reference  (8}  with  respect  to  their  potential  usefulness  in  the 
hardware  resource  allocation  algorithm: 


and 


Dj(l  J)  = 


E 

K*l 

nM 

E 

K=l 


I 

|P(1,K)1  - !P(J,K)I  I 


|P(I,K)1  + |P(J,K)I 


Dj(I.J) 


fi  |P(1.K)|  - |P(J,K)I  1 1 

Lu  [(IP(I,K)|  + |P(J,K)I+ 1)] 


The  following  remarks  apply: 

Note  that  both  measures  make  sense  only  for  non-negative  data.  This  is  the  reason 
for  using  only  the  absolute  values  of  the  elements  of  matrix  P in  D,  and  D, . 

Measure  D,  should  normally  be  used  for  binary  data  only. 

D,  and  D,  measure  the  degree  of  agreement  between  two  programs;  i.e..  if  two 
programs,  1 and  J,  use  the  Kth  message,  weighted  by  M * iP(I.K)i=  IPU.KK 
for  communication,  then  the  corresponding  term  in  the  numerator  of  D,  (or 
D,  1 is  zero,  with  an  opposite  effect  occurring  in  the  denominator.  The  more 
simitar  two  programs  are.  the  smaller  will  be  the  value  of  D,  or  D, . 

During  a systematic  investigation  of  the  optimization  problem  stated  above,  attention  was 
focused  on  the  following  four  alternative  methods  for  solving  »hc  optimal  hardware  resource 
allocation  problem: 

(1)  An  enumerative  integer  programming  method,  called  Branch  and  Bound  Algorithm 

[reference  (9),  Chapter  4} 

(2)  A cluster  analysis  algorithm  known  as  MacQueen’s  K-Means  Method  (reference (10). 

Chapter  7 J 

(3)  A cluster  analysis  algorithm,  known  as  Forgy's  Method  (reference  (10),  Chapter  7] 

(4)  A heuristic  method,  which  is  presented  in  the  sequel  as  Algorithm  4. 
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ftreliminary  computational  results  indicate  the  superiority  of  MacQueen’s  Method  over 
methods  3 and  4 for  the  problem  und^r  consideration.  Therefore,  further  research  is  likely  to  be 
narrowed  down  to  methods  1 and  2.  To  make  method  1 (Branch  and  Bound  Algorithm) 
computationally  more  attractive,  bit  string  manipulation  techniques  have  been  used  to  handle  the 
enumeration  tree  on  which  the  method  is  based.  As  stated  earlier,  reference  [8]  discusses  the 
results  of  this  evaluation  effort  and  contains  a detailed  description  of  the  investigated  algorithms. 
(Although  the  problem  addressed  in  reference  (8)  differs  slightly  from  the  optimal  resource 
allocation  problem  for  DP/M,  the  results  generally  are  applicable  to  the  DP/M  case.)  Since 
method  4 has  been  formulated  in  the  course  of  DP/M  process  construction  studies  (actually,  it 
constitutes  an  extension  of  a procedure  mentioned  in  reference  (3)),  and  may  not  be  easily 
available  in  published  literature,  its  definition  has  been  included  in  the  present  report.  Its  main 
virtue  is  simplicity.  It  will  be  referred  tt  as  Algorithm  4D;  methods  1,  2,  and  3 will  be  referred 
to  as  Algorithms  4A,  4B,  and  4C,  respectively. 

ALGORITHM  4D:  SUBOPT1MAL  RESOURCE  ALLOCATION  ALGORITHM 


Npe  = Number  of  Processing  Elements  under  consideration 
NP  = Number  of  programs  under  consideration. 

Then  proceed  as  follows: 

1.  Initially  set  NPE  = Np.  Assign  one  program  per  PE.  Mark  all  pairs  of  PEs  eligible  for 
fusion.  Construct  the  list  of  all  eligible  pairs. 

2.  Find  an  eligible  pair  of  PEs  whose  fusion  into  a single  PE  (i.e.,  coalescence  of  the 
programs  resident  on  these  two  PEs  into  a single  PE)  would  eliminate  the  greatest 
amount  of  bus  traffic. 

3.  Can  the  load  (memory  and  processing  speed  requirements)  already  assigned  to  the 
PEs  of  the  pair  considered  for  fusion  be  handled  by  a single  PE?  If  yes,  go  to  4: 
otherwise,  go  to  5. 

4.  Fuse  the  PEs  of  the  candidate  pair  into  a single  PE  and  coalesce  their  workloads. 
Decrease  NPt  by  1 . Modify  the  list  of  eligible  pairs.  Go  to  2. 

5.  Eliminate  the  pair  that  cannot  be  fused  from  the  list  of  eligible  pairs. 

6.  Are  there  any  eligible  pairs  left?  If  yes,  pick  one  and  go  to  2:  otherwise,  stop. 

d.  Identified  But  Not  Implemented  Process  Analysis  Algorif 1 ms 

There  is  only  one  key  process  an  alysis  algorithm  which  has  been  identified  in  the  process 
construction  procedure  of  Basic  Procrs  Constructor  (Subsection  IX.C)  but  was  not  implemented. 
Its  function  is  to  construct  the  maximally  paralle!,  determinate  predecessor-successor  graphs  for 
each  program  in  the  process  model.  A maximally  parallel  graph  that  generates  the  program 
determinacy  is  one  which  maximizes  the  potential  parallelism  in  the  program  execution  patterns 
without  jeopardizing  the  determinacy  of  computed  outputs.  An  execution  pattern  here  refers  to 
a sequence  in  which  the  program  tasks  (nodes)  are  to  be  executed.  The  input  data  needed  to 
construct  a maximatly-parallel,  determinate  predecessor-successor  graph  for  a program  is  the 
information  on  input-output  relations  between  the  tasks  constituting  the  program.  Once  this 
information  is  available,  many  such  graphs  can  be  constructed  for  a given  system  of  tasks,  all  of 
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which  are  logically  equivalent  but  different  in  complexity  (i.e.,  they  differ  in  the  number  of  links 
that  directly  connect  pairs  of  nodes),  it  can  be  proved  that  every  program  possesses  a unique 
maximally-parailel,  determinate  predecessor-successor  graph  of  minimum  complexity.  References 
(111,  (121,  and  (13)  discuss  parallel  predecessor-successor  graphs,  including  their  construction. 

C.  SUMMARY  OF  REQUIREMENTS 

This  subsection  summarizes  requirements  for  the  development  of  an  initial  version  of  the 
system  for  constructing  DP/M  real-time  processes.  This  initial  system  is  called  the  Basic  Processor 
Constructor  (BPC).  Various  problems  associated  with  its  development  have  already  been 
discussed  in  the  preceding  section  (Subsection  IX.B).  Although  an  attempt  has  been  made  to 
keep  this  summary  of  BPC  development  requirements  self-contained  at  the  cost  of  restating  a 
few  basic  concepts  and  definitions  already  introduced  in  the  problem  analysis  section,  certain 
references  to  that  section,  especially  to  the  subsection  which  discusses  process  construction 
algorithms,  ccutd  not  be  completely  avoided  for  reasons  of  conciseness. 

The  requirements  presented  in  the  sequel  have  been  divided  into  three  major  groups: 
System  requirements 
Functional  capability  requirements 
linplementational  requirements. 

The  system  requirements  view  the  Basic  Process  Constructor  as  an  integrated  system  of 
computer  programs  which  interfaces  with  its  main  user,  the  process  designer.  The  basic  process 
construction  procedure  defined  in  Subsection  IX.C.5  assumes  the  process  designer's  active 
participation  in  that  procedure,  which  occurs  through: 

Provision  of  process  construction  inputs  (mainly  the  model  data)  by  the  designer 
Monitoring  of  intermediate  resutts 

Optional  intervention  in  the  computerized  procedure  in  order  to  influence  its  further 
progress. 

The  computer  programs  constituting  the  BPC  intercommunicate  through  shared  data  files; 
i.e.,  the  intermediate  outputs  produced  by  one  program  are  used  as  inputs  to  other  programs. 
The  final  outputs  of  a process  constructor  are  to  be  used  as  inputs  either  for  process  simulation 
on  a host  computer  or  else  for  exei  uting  the  process  on  a target  DP/M  system. 

BPC  system  requirements  cover  the  following  areas: 

The  interaction  of  process  construction  with  other  phases  of  process  development 
and  the  interface  of  BPC  with  other  systems  (Subsection  IX.C.2) 

The  assumptions  made  about  the  process  development  language  (Subsection  IX.C.3) 


"Coffman,  Jr.,  E.  G.,  and  P.  J.  Denning:  Operating  Systems  Theory,  Prentice-Hall,  Inc..  Englewood  Cliffs,  N.  J., 
1973. 

uBcmstein,  A J.:  “Analysis  of  Programs  for  Parallel  Processing,”  IEEE  Trans.  Comp.  EC-15.  4 5 October  1966). 
pp  757-762. 

uBaer,  J.  L:  “A  Survey  of  Some  Theoretical  Aspects  of  Multiprocessing,”  ACM  Computing  Surveys,  5,  41 
(March  1973). 


400 


A supporting  subsystem,  called  the  Process  Development  Information  System 
(PDIS),  whose  function  is  to  facilitate  handling  of  the  process  development 
data  base  (Subsection  IX.C.4). 

The  functional  capability  requirements  define  the  process  construction  which  the  BPC 
m :st  be  capable  of  accomplishing.  These  requirements  are  stated  by  specifying  a fundamental 
process  construction  procedure  which  consists  of  the  following  major  steps/actions: 

Analysis  and  reduction  of  the  process  construction  input  data 

Process  decomposition  analysis,  whose  functions  are  to 

Decompose  a computer-independent  model  of  the  process  into  individual 
DP/M  programs  so  that  none  of  them  will  exceed  the  real-time  capacity 
of  a single  DP/M  processing  element 

Validate  the  structural  correctness  of  each  program 

Construct  computer-dependent  program  models. 

Process  synthesis,  whose  main  function  is  to  determine  an  optimal  hardware 
configuration  by  obtaining  the  best  possible  mapping  of  programs  into 
Processing  Elements. 

Generation  of  the  process  model  data  for  simulation  or  for  actual  execution  in  real 
time. 

The  functional  capability  requirements  are  stated  in  Subsections  IX.C.S  and  1X.C.6;  the 
first  of  these  two  sections  defines  the  fundamental  process  construction  procedure  of  the  BPC, 
and  the  second  one  summarizes  the  algorithms  and  the  external  inputs/outputs  of  that 
procedure.  For  several  reasons,  no  attempt  was  made  to  specify  the  detailed  organization  and 
formats  of  the  data  set,  or  files  that  have  been  identified  in  the  fundamental  process 
construction  ptocedure.  For  example,  the  file  organization  and  formats  depend  on  the  selection 
of  the  host  computer  on  which  the  BPC  is  to  be  implemented;  and  also,  it  is  not  known  at  the 
present  time  in  what  form  the  process  construction  inputs  will  come  (which  to  some  extent 
uepinds  on  the  capabilities  of  the  process  development  language  processor)  ;nd  precisely  what  all 
output  data  should  be  (it  depends  on  the  final  design  of  the  DP/M  real-time  executive). 

The  few  implementation!  requirements  that  could  be  identified  at  the  present  time  define 
the  expected  minimum  capabilities  of  the  host  computer  system.  They  are  summarized  in 
Subsection  IX.C.7. 

1.  Assumptions 

This  subsection  contains  a summary  of  the  basic  assumptions  about  the  DP/M  hardware 
and  software  from  which  the  DP/M  process  construction  requirements  have  been  derived.  For 
convenience,  these  assumptions  have  been  separated  into  those  on  hardware,  software  process, 
and  the  process  dynamics  at  exectuion  time. 

a.  Hardware 

In  a DP/M  network,  the  microprocessors,  called  processing  elements  (PEs),  are  grouped 
into  one  or  several  clusters  (Affinity  Groups).  All  PEs  within  a single  cluster  communicate 
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through  a Local  bus.  A Global  bus  is  used  to  support  commur  station  between  any  two  PEs  that 
are  located  in  two  different  clusters.  The  exact  configuration  of  each  cluster  is  determined  at 
process  construction  time  by  the  avionics  functions  that  have  been  assigned  to  it  and  by  the 
external  I/O  that  it  must  service. 

A PE  can  be  characterized  as  a 16-bit  parallel  microcomputer  with  a 4K  to  8K  memory 
and  the  computational  power  of  250K  operations/second.  High-density,  low-power  LSI 
technology  is  to  be  used  to  implement  the  hardware. 

Any  PE  can  be  made  to  communicate  with  the  external  world  (i.e.,  sensors  and  actuators) 
through  a direct  parallel  I/O  channel,  each  of  which  is  dedicated  to  a particular  function.  Note 
that  a sensor  or  an  actuator  can  be  directly  connected  only  to  a single  PE  in  the  network;  this 
implies  that  the  other  PEs  can  communicate  with  such  an  external  device  only  through  the  PE  to 
which  the  device  is  connected. 

b.  Structure  of  the  Software  Process 

The  process  consists  of  the  avionics  programs,  the  executive  software,  and  the  supporting 
; data  base.  The  avionics  software  is  structured  along  the  lines  of  avionics  functions  (such  as 

navigation,  weapon  control,  etc.)  into  a set  of  programs  which  are  semi-autonomous  with  regard 
' to  hardware  resource  allocation  at  process  construction  time  and  to  scheduling  at  execution  time. 

Each  program  in  the  process  is  characterized  by  its  expected  iteration  rate,  the  I/O  messages  that 
it  consumes  or  produces,  and  the  rules  to  be  used  to  schedule  it.  Ea  -h  program  can  be  visualized 
as  a network  of  tasks,  where  the  I/O  relations  between  individual  tasks  determine  their 
precedence-successor  constraints, 
i 

The  structure  of  each  program  in  the  process  model  is  defined  by  the  following  two 
l related  graphs  whose  nodes  represent  individual  tasks  (functional  segments)  of  the  program: 

| The  program  graph  defines  all  potentially  possible  execution  paths  through  the  task 

! system  constituting  a program. 

The  precedence-successor  graph  defines  all  precedence-successor  constraints  in  the 
< program  due  to  the  I/O  relations  between  the  individual  tasks;  it  also  shows 

i parallel  path  substructures  of  the  fork  and  join  type;  all  constituent  tasks  of 

such  a parallel  substructure  must  be  executed  before  the  paths  join  together. 

One  of  the  initial  tasks  in  the  process  construction  procedure,  to  be  defined  later  in  the  sequel, 
i is  to  construct  a maximally-parallel.  determinate  precedence-successor  graph  for  each  program  in 

the  process  model.  The  program  graph  can  then  be  easily  derived  from  such  a 
precedence-successor  graph. 

The  following  assumptions  have  been  made  about  the  structure  of  each  program: 

It  has  precisely  one  entry  node  (task) 

It  has  precisely  one  exit  node  (task) 

There  are  no  closed  loop  cycles  through  nodes,  i.e..  all  program  loops  must  be 
embedded  within  individual  nodes  (tasks). 
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A program  satisfying  these  conditions  is  said  to  be  structurally  correct.  One  of  the 
functions  of  process  construction  is  to  validate  assertions  about  the  structural  correctness  of 
programs. 

Any  program  eventually  must  be  mapped  into,  or  reside  in,  a single  processing  element.  If 
a program  exceeds  the  available  capacity  of  a processing  element,  it  must  be  split  into  several 
programs  at  process  construction  time.  At  the  start  of  process  construction,  the  process  is 
divided  into  programs  along  the  natural  functional  boundaries  of  avionics  functions,  such  that 
each  (sub)function  is  represented  by  precisely  one  program.  On  completion  of  process 
construction,  each  function  is  represented  by  one  or  several  programs,  depending  on  whether  the 
representing  nrogram  had  or  had  not  been  split,  respectively. 

e.  Process  Dynamics  at  Execution  Time 

The  execution-time  communication  between  individual  process  modules  and  between  the 
process  and  the  external  world  occurs  through  the  flow  and  exchange  of  I/O  messages.  Not  all 
I/O  messages  generate  bus  traffic;  for  example,  some  messages  may  be  exchanged  between  the 
process  modules  which  reside  in  the  same  PEs.  Messages  which  flow  between  a PE  and  an 
external  device  directly  connected  to  it  also  do  not  generate  any  bus  traffic.  All  I/O  messages 
can  be  divided  into  three  types:  external  I/O,  interprogram  I/O,  and  intraprogram-intertask  I/O 
messages. 

It  is  assumed  that  each  external  I/O  device  (sensor  or  actuator)  interfaces  with  the  process 
through  an  I/O  handling  program,  called  the  External  I/O  Handler.  An  External  I/O  Handler 
must  always  be  placed  in  the  same  PE  to  which  the  external  I/O  device  is  connected.  To  the 
mission-oriented  programs  of  the  process,  an  External  I/O  Handler  looks  like  any  other  program: 
it  may  produce  outputs,  which  actually  come  from  a sensor  and  which  may  be  consumed  by 
other  programs,  or  vice  versa.  Thus,  if  a program  has  not  been  placed  in  the  same  PE  with  a 
companion  Ext*"*-'  I/O  Handler  which  is  transmitting  external  inputs  to  the  program,  the 
resulting  information  flow  will  cause  bus  traffic.  (A  similar  statement  can  be  made  about 
external  outputs.)  One  of  the  functions  of  process  construction  is  to  minimize  the  potential  bus 
traffic  by  collocating  programs  with  their  External  I/O  Handlers  in  the  same  Processing  Elements, 
especially  those  that  intercommunicate  heavily  at  execution  time.  The  interprogram  I/O  results  in 
the  bus  traffic  only  if  the  intercommunicating  programs  are  located  in  different  PEs.  Thus,  the 
total  bus  traffic  can  be  decreased  by  trying  to  locate  the  most  heavily  intercommunicating 
programs  in  the  same  PEs.  The  intraprogram-intertask  I/O  does  not  generate  any  bus  traffic  at 
execution  time,  but  it  has  the  potential  to  generate  bus  traffic  in  the  event  that  the  program  is 
further  decomposed  into  several  programs.  Therefore,  the  intraprogram-intertask  I/O  is  a factor 
to  be  watched  when  a program  is  split  into  several  programs  at  process  construction  time. 

2.  Interaction  With  Other  Pluses  of  Process  Development 

and  With  Other  Systems 

The  process  construction  procedure  of  Bas;c  Process  Constructor  (BPC)  interacts  with  the 
following  aspects  or  phases  of  process  development: 

Logical/functional  design  of  the  process- for  decomposition  of  the  process  into 
major  functional  components  and  description  of  the  process  interfaces  with 
the  external  world  (sensors  and  actuators) 
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Compilation  outputs-by  using  compilation  outputs  as  input  information  for 
construction  of  the  computer-independent  program  models 

Process  development  simulations-by  producing  the  process  construction  outputs 
which  later  are  to  be  used  as  inputs  for  system  network  or  functional 
simulation 

Functional  model  of  the  real-time  executive-by  producing  the  process  construction 
outputs  which  constitute  the  control  data  used  by  the  real-time  executive  for 
process  initialization  and  simulated  real-time  operations 

Functional  model  of  bus  operations-to  produce  the  control  data  used  to  simulate 
the  bus  traffic 

Functional  model  of  DP/M  hardware-to  obtain  running  time  estimates. 

Hence,  the  BPC  must  be  designed  to  interface  properly  with  the  following  process 
development  subsystems: 

With  the  language  which  is  to  be  used  for  processing  the  process  software,  and 
especially  with  th-  compilation  output* 

With  system  network  and  functional  simulators 
With  process  (or  process  model)  loaders. 

In  addition,  the  programs  of  the  BPC  must  interface  with  the  Pro<-e  • Development  Information 
System  for  handling  the  process  construction  inputs,  outputs,  and  intermediate  results. 

3.  Programming  Languages 

This  subsection  states  the  requirements  for  the  programming  languages  associated  with  the 
development  of  DP/M  processes.  Potentially,  two  programming  languages  may  be  involved:  that 
used  for  coding  the  process  software  (Process  Development  Language)  and  that  used  for  coding 
the  process  development  support  software,  including  the  BPC  (Support  Programming  Language). 
Although  the  long  range  "oal  is  to  have  a single  high-order  programming  language  for  ail  purposes 
(i.e„  for  process  as  well  as  for  support  software),  such  a goal  probably  is  unrealistic  for  the 
initial  time  period  during  which  the  BPC  is  to  be  used.  Therefore,  programming  requirements  for 
the  two  cases  have  been  stated  separately. 

a.  Programming  Language  for  Support  Software 

A single  programming  language  which  possesses  the  characteristics  listed  below  is 
considered  sufficient  for  coding  all  support  software,  i.e.,  the  Basic  Process  Constructor,  all 
process  simulators  and  process  development  utility  routines.  This  language,  to  be  called  the 
Support  Programming  Language  (SPL).  shall 

1.  Be  a scientific  programming  language  with  general  capabilities  similar  to  those  of 
FORTRAN 

2.  Have  the  facility  for  allocating/deallocating  pointer-addressable  storage  blocks  for 
program  variables  at  execution  time  (this  feature  is  similar  to  the  controlled  storage 
with  BASE  attribute  in  PL/I) 


3.  Have  list  processing  operators  (such  as  CREATE  or  DEFINE  a list,  ADD  an  element 
to  a list,  DELETE  a specified  element  from  a list,  FIND  an  element  in  a list)  for 
linked  lists 

4.  Have  character  string  operators  for  concatenating  two  strings,  finding  a substring  in  a 
string,  copying  a substring  from  a string,  and  making  string  substitutions  (assignment 
statement). 

Another  feature  which  is  highly  desirable  but  which  will  not  be  put  as  a requirement  is  the 
capability  to  have  the  data  of  record  type  and  to  refer  directly  to  the  individual  fields  in  a 
record  (similar  to  the  PL/I  structures  or  the  “data  of  type  record”  in  PASCAL).  Requirements  2, 
3,  and  4 may  be  satisfied  by  implementing  the  capabilities  specified  above  in  the  form  of  special 
subroutine  packages.  In  such  a case,  a FORTRAN-like  programming  language  may  be  used  as  a 
basis  for  the  Support  Programming  Language. 

t.  Process  Development  Language 

Process  modules,  or  models  of  such  modules,  will  be  coded  using  the  Process  Development 
Language  (PDL).  Programs  coded  in  this  language  may  interface  with  the  process  construction 
procedure  of  Basic  Process  Constructor  through  the  process  construction  input.  This  interface  is 
considered  because  certain  model  data,  specified  below  and  needed  in  process  construction,  can 
at  least  theoretically  be  generated  as  a by-product  of  compilation. 

To  minimize  the  manual  preparation  of  process  construction  inputs,  the  compiler  of  the 
Process  Development  Language  shall  be  capable  of  producing  the  model  information  described 
below  as  a by-product  of  compiling  a process  module: 

Description  of  the  I/O  variables  used  by  the  module  for  intermodule  and  external 
communication 

Names  of  the  standard  (common)  subroutines  called  by  the  module 

Characteristics  of  the  module  with  regard  to  its  demand  on  hardware  resources 
(storage,  instruction  counts,  loop  statistics,  and  perhaps,  timing) 

Information  about  the  module’s  hierarchical  position  in  the  logical  structure  of  the 
process  (i.e.,  whether  it  represents  a function  or  a task,  and  to  which  part  of 
the  process  it  belongs). 

The  compiler  of  PDL  shall  be  capable  of  producing  this  ir  formation  in  a form  suitable  for 
automatic  retrieval  from  compilation  outputs. 

Since  conventional  compilers  are  not  capable  of  producing  all  the  above-listed  information, 
the  following  implementation]  approach  is  suggested  as  an  interim  solution.  If  certain 
restrictions  on  programming  conventions  are  obeyed,  then  compilation  may  be  able  to  produce 
additional  information  which  otherwise  would  be  unavailable.  For  example,  one  may  require  that 
all  I/O  variables  be  specified  explicitly  in  a reserved  part  of  each  program:  if.  in  addition,  special 
comment  phrases  are  reserved  for  lescribing  these  variables,  then  it  may  be  possible  to  obtain,  as 
a by-product  of  compilation  by  a conventional  compiler,  nearly  all  information  that  is  needed  to 
describe  the  I/O  variables  for  process  construction.  For  that  purpose,  it  may  also  be  necessary,  or 
desirable,  to  develop  a special  post-compilation  text  processor  whose  function  would  be  to 
extract  from  the  compilation  output  the  data  items  of  interest,  and  then  to  edit  and  store  them 
in  a form  that  can  he  directly  input  to  the  process  construction  procedure. 


j 4.  Process  Development  Information  System 

The  Process  Development  Informatbn  System  (PDIS)  is  a compute*-  based  system  whose 
function  is  to  facilitate  the  management  and  use  of:  (1)  computer  programs  associated  with 
process  development  (there  will  be  two  types  of  such  programs-the  process  development  support 
programs  and  the  programs  of  the  process  being  developed),  and  (2)  the  data  used  or  produced 
by  these  programs.  In  more  detail,  the  functions  of  PDIS  are  to 

Increase  the  effectiveness  of  process  designers  and  programmers  -by  minimizing  the 
amount  of  manual  work  needed  for  data  preparation  and  transfer 

Facilitate  the  management  control  over  process  development  -by  making  the  process 
! data  and  software  readily  accessible 

! 

j Facilitate  automation  of  system  documentation 

j Protect  the  stored  information  and  control  access  to  it. 

I 

| The  availability  of  PDIS  is  considered  to  be  the  key  factor  in  automation  not  only  of 

process  construction,  but  also  of  other  phases  of  process  development,  especially  of  simulations. 
Therefore,  a PDIS  shall  be  developed  as  a support  subsystem  for  the  BPC.  The  purpose  of  the 
present  subsection  is  to  .state  minimal  capability  requirements  for  the  design  of  PDIS. 

To  handle  the  real-time  software  development  for  the  avionics  processes  which  are  to  be 
1 actually  deployed  in  the  field,  advanced  versions  of  the  process  constructor,  possessing  a more 

powerful  information  system  than  one  specified  here  in  the  sequel,  shall  be  needed.  This 
information  system  w’ll  differ  from  the  PDIS  of  the  BPC  mainly  in  the  following  three  aspects: 

It  will  be  accessible  through  interactive  remote  terminals 

It  will  provide  the  process  designer  with  data  and  program  edit  capabilities  through 
, interactive  remote  terminals 

I 

It  will  be  capable  of  providing  extensive  services  for  retrieving  information  from  the 
j process  development  data  base. 

| Since  the  cost  of  including  the  above  three  features  is  relatively  high,  they  have  been  omitted 

| from  the  BPC  requirements. 

j a.  Summary  of  Functional  Capability  Requirements 

j and  Implementations!  Considerations 

The  PDIS  which  is  to  be  used  to  support  the  BPC  shall  be  capable  of 

Making  it  possible  for  the  BPC  programs  to  communicate  through  shaied  data 
sets/files 

Building  up  and  maintaining  model  data  sets  to  be  used  as  program  inputs 
Storing  and  saving  program  outputs  for  future  use 

Retrieving  the  stored  data  for  examination  or  editing  purposes~by  locating, 
displaying  and  producing  a hard  copy  (printed  report  or  punched  cards)  of  it 

Controlling  the  access  to  the  data  base  in  order  to  protect  the  stored  information 

Providing  management  control  information  on  the  state  of  the  data  base. 
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The  Process  Development  Information  System  shall  contain  two  types  of  libraries.  The 
Data  Library  will  handle  the  model  data  and  simulation  outputs,  and  the  Program  Library  will 
store  the  source  and  object  modules  of  the  process  model  and  support  (process  constructor  and 
simulator)  software.  The  PDIS  shall  be  implemented  on  a host  developmental  computer.  On  that 
computer  system,  PDIS  shall 

Be  designed  to  utilize  to  the  greatest  extent  all  standard  processing  and  utility 
services  provided  by  that  system 

Be  capable  of  interfacing  with  the  Process  Development  Language  translator  in  order 
to  retrieve  the  source  modules  for  compilation  and  to  store  the  object 
modules  for  future  use 

Interface  with  the  user  through  the  standard  access  facilities  of  the  host  computer 
(although  the  computer  access  through  an  interactive  remote  terminal  is  very 
desirable,  a terminal  equipped  with  a card  reader  and  a line  pri.iter  is 
considered  to  be  adequate  for  the  BPC  operations). 

The  question  whether  it  is  better  to  use  a standard  Data  Management  System  package, 
which  has  approximately  the  same  functional  capabilities  as  specified  in  the  present  subsection, 
or  to  custom-design  and  program  the  required  Data  Library  utility  subroutines  is  not  addressed 
here.  This  decision  is  a complex  function  of  the  availability  and  suitability  of  such  a standard 
package,  budget,  development  schedules,  and  availability  of  talent.  Therefore,  it  should  be 
deferred  until  the  actual  development  of  the  BPC  has  been  started.  Since  most  computer  systems 
provide  reasonable  software  management  facilities,  the  Program  Library  shall  be  developed  on  the 
basis  of  existing  facilities. 

b.  Access  Control 

Two  basic  types  of  access  control  may  be  considered: 

The  access  control  to  protect  the  integrity  of  the  information  stored  in  PDIS 
libraries 

The  access  control  for  screening  the  users  trying  to  retrieve  classified  information. 

Both  rypes  of  access  control  may  be  needed  for  the  PDIS  of  an  advanced  process 
constructor.  Since  the  applications  of  BPC  will  probably  not  involve  the  use  of  any  classified 
information,  it  is  sufficient  to  provide  the  BPC  only  with  the  access  control  for  protecting  the 
integrity  of  the  Data  Library.  Pro'ection  of  software  is  to  be  limited  to  the  standard  access 
control  facilities  provided  by  the  Operating  System  of  the  host  computer. 

In  the  BPC,  the  protection  of  the  Data  Library  (dictionaries  as  well  as  data  files)  shall  be 
accomplished  by  forcing  the  user  to  communicate  with  the  library  always  through  standard  PDIS 
utility  subroutines.  These  subroutines  shall  be  capable  of  preventing  users  from  writing  into  or 
destroying  data  files  that  do  not  belong  to  them. 

c.  The  PDIS  Data  Library 

The  basic  function  of  the  PDIS  Data  Library  is  to  integrate  the  individual  computer 
programs  and  procedures  (not  necessarily  computerized ).  constituting  the  BPC.  into  a 
computerized  system  by 
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Facilitating  the  flow  of  information  through  the  components  of  the  BPC  and,  in 
particular,  the  sharing  of  data  between  such  components 

Establishing  a data  interface  with  the  DP/M  simulators 

Facilitating  the  input  of  information  into  the  process  construction  procedure. 

In  more  advanced  versions  of  Process  Constructor,  the  input  interface  shall  be  expanded  to 
include  partial  outputs  of  the  Process  Development  Language  translator.  Since  no  such  special 
language  is  absolutely  needed  and  is  not  foreseen  during  the  initial  process  construction  work, 
developing  an  automated  input  interface  may  be  economically  unacceptable,  and  so  the  initial 
inputs  to  Process  Construction  Procedure  will  probably  have  to  be  keypunched. 

( 1 ) Organization  of  the  PD1S  Data  Library 

The  PD1S  Data  Library  shall  consist  of  a D ta  Library  directory  system,  the  data  base,  and 
the  Data  Library  utility  subroutines.  The  data  base  shall  be  organized  on  three  hierarchical  levels. 
On  the  highest  level,  the  entire  data  base  shali  consist  of  one  or  several,  possibly  overlapping, 
user’s  libraries.  Each  user’s  library  may  contain  one  or  several  user’s  (or  logical)  files,  each  such 
file  shall  consist  of  records. 

(2)  Records 

A record  may  be  ot  variable  length.  The  head  portion  of  the  record  (record  header)  shall 
be  of  fixed  length  for  all  records  in  the  data  library  and  shall  contain  the  record  length,  the 
record  lo  number  (key),  and  the  record  sequence  number  for  the  record  group  (or  type) 
identif  ed  ny  the  record  ID  number 

Sufficient  space  shall  be  reserved  in  the  record  header  for  the  addition  of  following 
optional  information 

The  time  and  data  of  record  deposition  (creation) 

A forward  pointer  to  the  next  record  of  the  same  type  (key)  in  the  same  file 

A backward  pointer  to  the  last  record  of  the  same  type  (key)  in  the  same  file 

The  first  optional  item  above  is  especially  needed  for  simulation  output,  the  last  two  are  needed 
in  construction  of  singly-threaded,  doubiy-unked  lists  through  the  data  base. 

Each  file  shall  have  an  initial  head  record  of  the  same  general  format  as  described  above, 
except  that  key  of  the  record  snail  be  ol  the  special  type  reserved  for  file  heads  only  the 
variable  part  of  that  record  shall  contain  the  file  name  description. 

(3)  Directory  System  and  Directory  Operations 

The  directory  system  shall  consist  of  a Master  Directory'  and  one  or  several  1'ser’s 
Directories,  each  identified  by  the  user’s  name  The  Master  Directory  shall  contain  references  to 
the  User's  Directories;  a User’s  Directory,  to  th*>  user’s  files. 

As  indicated  earlier,  file  sharing  between  users  shall  be  allowed.  Therefore,  a file  in  the 
Data  Library  shall  be  capable  of  belonging  to  one  or  several  user’s  libianes  simultaneously  The 
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file  naming  system  shall  make  it  pcsible  for  a user  to  refer  to  a file  by  more  than  a single  name 
and  several  users  to  refer  to  the  same  file  by  different  names. 
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(4)  Access  Control 

The  Data  Library  access  control  mechanism  shall  allow  two  modes  of  operation,  for  file 
modification: 

In  the  read-only  access  mode,  the  users  are  allowed  to  modify  or  logically  delete 
(but  not  purge)  their  own  files  only,  including  those  that  they  share  with 
other  users  through  the  directory  system 

In  the  unrestricted  access  mode,  the  users  are  allowed  to  modify,  logically  delete,  or 
purge  (physically  delete)  any  file  in  the  library. 

There  shall  be  no  access  restrictions  for  reading  (copying)  of  files. 

(5)  Data  Library  Utility  Subroutines  and  Their  Operations 

All  user's  communication  with  the  Data  Library  shall  be  channeled  through  a standard  set 
of  Data  Library  utility  subroutines.  These  subroutines  shall  be  capable  of  carrying  out  the 
following  library  use  funct>ons/operations: 

( 1 ) Data  Library  Funetions'Operations: 

initialize  the  Data  Libraiy  and  create  the  Master  Directory 

Copy  the  Master  Directory  into  the  working  area  and/or  print  its  contents 

Purge  all  logically  deleted  users  files  from  the  Data  Library  (a  shared  file  must 
have  been  logically  deleted  by  all  its  former  users):  if  all  files  of  a User’s 
Library  have  been  logically  deleted  and  purged,  the  UserL  Directory  is 
purged  from  the  directory  system 

(2)  User's  Library  Functions  Operations: 

Initialize  a User’s  Library  and  create  its  directory 

Copy  a User’s  Directory  into  the  specified  working  area  and/or  print  'ts 
contents 

A<_d  a file  to  a User's  Library  by  copying  it  from  the  working  area 

Find  and  copy  a file  from  a User’s  Library  into  the  working  area 

Logically  delete  a single  file  from  a User’s  Library  (i.e..  the  file  may  still 
remain  m the  libraries  of  other  users) 

l.oe.eally  delete  all  files  from  a User’s  Library  and  record 

(3)  File  and  iecord  functions  operations  'or  a file  located  in  a temporary  working  area: 

Indiali/e  a file  in  a working  area 

Add  i correctly  tormatted  record  to  the  file 

Find  the  next  record  with  a given  key  in  the  file  (this  operation  is 
progressively  repeatable) 

Delete  a record  from  the  file. 
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The  following  remarks  apply: 

Each  user’s  file  shall  be  organized  sequentially.  It  is  up  to  an  individual  user  to 
establish  lists  within  his  file  if  he  needs  to  do  so-the  pointer  space  for  that 
purpose  is  reserved  in  the  fixed  length  header  portion  of  each  record. 

In  all  above  described  library  functions/operations,  it  is  assumed  that  all  directories 
affected  by  a libiary  or  file  modification  are  automatically  modified 
subsequent  to  such  a function  operation. 

(6)  The  PDIS  Program  Library 

As  already  stated,  the  PDIS  Program  Library  shall  be  built  on  the  standard  software 
management  facilities  already  available  in  the  computer  system  on  which  the  Basic  Process 
Constructor  is  to  be  implemented. 

5.  Functional  Specification  of  the  Process  Construction  Procedure 

a.  Overview 

This  subsection  summarizes  the  functional  capability  requirements  of  the  DP/M  process 
construction  by  defining  a canonical  procedure  to  be  used  in  the  Basic  Process  Constructor.  (In 
the  sequel,  this  procedure  is  referred  to  as  process  construction  procedure. ) The  Basic  Process 
Constructor  essentially  is  a system  of  computerized  algorithms  which  interacts  with  the  process 
designer.  The  programs  constituting  this  system  communicate  through  common  data  files  which 
are  accessed  through  the  facilities  of  the  PDIS  Data  Library.  The  inputs  for  the  Basic  Processor 
Constructor  are  prepared  by  the  process  designer.  Two  basic  input  sets  are  used:  one  describes 
the  target  DP/M  computer  system  for  which  the  process  is  to  be  constructed;  another  describes 
the  process  itself.  The  process  is  defined  by  specifying 

Its  partitioning  into  avionics  subfunctions/iunctions 

The  tasks  constituting  each  subfunction  in  terms  of  their  scheduling  rules  and  their 
demands  on  hardware  resources 

Ail  external,  interfunction,  and  intrafunction-intertask  I/O. 

As  the  process  construction  starts,  it  is  assumed  that  each  subfunction/function  is 
designated  to  become  a DP/M  program  whose  tasks  represent  its  procedures  (routines).  As  the 
process  construction  progresses,  it  may  turn  out  that  some  programs  representing  avionics 
subfunctions/functions  do  exceed  the  capacity  of  a single  DP/M  Processing  Element.  Such  a 
program  is  then  split  into  several  separate  programs  which  are  to  be  distributed  over  several  PEs. 
Thus,  by  the  end  of  process  construction,  each  avionics  subfunction/function  has  been  converted 
into  a single  DP/M  program  or  into  an  integral  number  of  such  programs. 

b.  Process  Construction  Procedure 

The  multi-step  procedure  of  the  Basic  Process  Constructor  is  described  next.  Although  this 
procedure  is  to  be  computerized  extensively,  the  user  shall  have  the  option  at  the  end  of  each 
step  to  analyze  the  process  construction  data  generated  up  to  that  pomi  and  to  overrule  certain 
decisions  made  by  the  computerized  algorithms.  Having  this  option  greatly  increases  the 
flexibility  of  the  procedure  and  is  important  in  the  case  of  hardware  resource  allocation,  for 
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what  is  optimal  for  a particular  situation  may  not  precisely  fit  the  generalized  optimality  models 
used  in  process  construction  algorithms. 

Another  feature  of  the  procedure  is  that  is  that  it  shall  document  the  process  by 
producing  computer-printed  reports.  These  reports  shall  serve  several  purposes,  the  main  ones  of 
which  are  (1)  system  documentation  for  configuration  and  management  control  and  (2)  to 
p ovide  the  process  designer  with  information  needed  in  decision  making,  especially  with  regard 
to  overruling  or  influencing  the  computerized  process  construction  procedures.  The  final  output 
of  the  process  construction  procedure  shall  contain  the  model  and  control  data  to  be  used  as 
simulation  input.  This  data  shall  be  organized  and  formatted  so  as  to  be  directly  inputtable  into 
the  appropriate  DP/M  simulators. 

The  process  construction  procedure  shall  consist  of  the  following  nine  steps: 

Generate  computer-independent  models  of  process  programs 

Analyze  and  model  the  process  I/O  and  storage  requirements 

Generate  a computer-dependent  process  model  (i.e..  the  timing  data  for  each  task  of 
every  process  program) 

Analyze  process  decomposition  (i.e..  determine  the  execution  paths  and  validate  the 
structural  correctness  of  every  program:  construct  synthetic  models  for  all 
programs) 

Evaluate  process  decomposition  in  order  to  test  whether  a process  component 
exceeds  the  hardware  constraints 

Synthesize  the  process  (i.e..  optimally  allocate  hardware  resources  to  programs  and 
determine  the  hardware  configuration) 

Generate  I/O  control  data 

Generate  program  execution  control  data 

Load  all  control  data,  link  and  load  process  components  (now  the  process  is  ready 
to  be  executed  or  simulated) 

Figure  171  is  a block  diagram  of  the  process  construction  procedure.  To  simplify  the 
diagram,  not  all  printed  reports  to  be  produced  are  shown  in  it.  Next,  each  of  these  steps  is 
described  in  more  detail. 

STEP  I:  GENERATION  OF  A COMPUTER-INDEPENDENT  PROCESS  MODEL 

Process  construction  starts  with  the  generation  of  computer-independent  models  of  all 
process  modules.  The  inputs  to  the  first  step  may  be  in  two  forms: 

As  an  automatically  generated  by-product  of  compiling  the  source  programs  which 
constitute  avionics  functions  and  tasks 

As  . e data  obtained  from  the  manual  analysis  oi  avionics  algorithms. 

A computerized  algorithm,  called  Computer-independent  Model  Generator  (CIMG). 
analyzes  the  input  data  to  do  the  following: 

Define  the  overall  process  structure  by  identifying  its  programs,  including  their 
scheduling  rules  and  iteration  rates. 
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Identify  the  program  inputs  and  outputs  which  are  due  either  to  the  interprogram 
information  flow  or  to  the  communication  of  the  process  with  the  outside 
world  (external  I/O);  identify  the  storage  requirements  of  the  data  sets  and 
buffers  to  be  used  for  storing  these  inputs  and  outputs. 

Decompose  each  program  into  tasks  and  define  the  intertask  information  flow  :n  the 
form  of  task  I/O  lists;  identify  the  storage  requirements  of  the  data  sets  used 
for  interprogram-intertask. 

For  each  task,  determine  the  amount  of  required  computational  work  in  .erms  of 
operation  counts  and  loop  repetition  estimates.  (Note  that  ♦nere  are 
alternative  techniques  for  obtaining  the  running-time  estimates.  Fcr  example, 
if  the  task  already  exists  as  a subroutine,  it  might  be  executed  on  the  target 
computer  or  simulated  on  an  instruction-level  simulator  m order  to  determine 
its  timing  experimentally;  another  approach,  which  is  recommended  but  which 
may  be  unrealizable  for  the  Basic  Process  Constructor,  is  to  use  a “smart” 
compiler  which  would  extract  model  information  as  a by-product  of 
compilation.) 

Determine  the  total  amount  of  storage  required  by  each  task. 

The  tasks  listed  above  essentially  represent  transformations  which  convert  and  reduce  the  in;  ut 
information  to  a form  suitable  to  process  construction.  For  the  initial  decomposition  of  the 
process  into  programs,  it  shall  be  assumed  that  each  avionics  subfunction  is  going  to  constitute  a 
DP/M  program. 

After  analyzing  and  reuu. the  above  indicated  model  data,  the  CIMG  shall 

Analyze  the  intertask  information  flow  in  each  program  to  construct  (a)  the 
maximally  parallel  predecessor-successor  graph  which  guarantees  program 
execution  determinacy  and  (b)  the  related  program  graph  which  describes  all 
potentially  possible,  alternative  paths  through  the  program  (as  noted  »r« 
Subsection  1X.B.  these  two  graphs  are  related  one  to  another  but  are  not  the 
same) 

Compact  and  write  the  reduced  model  data,  including  both  graphs,  on  the 
Computer-Independent  Model  File 

Print  a report  documenting  the  computer-indepei.dent  model  of  the  process. 

STEP  2:  GENERATION  OF  A COMPUTER-DEPENDENT  PROCESS  MODEL 

A Basic  Process  Constructor  program,  called  the  Compuier-Dependent  Model  Generator 
(CDMG),  now  converts  the  computer-independent  program  models,  produced  in  Step  I and 
stored  on  the  Computer-Independent  Model  File,  to  a computer-dependent  form  by  estimating 
the  task  running  times  and  the  task  memory  requirements  (the  latter  is  done  by  considering  the 
word  length  of  the  target  computer).  This  program  uses  two  streams  of  inputs:  (1)  computer 
hardware  definition  and  (2)  the  computer-independent  model  of  the  process:  it  produces  the 
following  outputs; 

A computer-dependent  description  of  individual  tasks,  grouped  under  programs  to 
which  these  tasks  belong,  which  is  written  on  Computer-Dependent  Model  File 

A printed  report  separately  documenting  each  task  of  every  program  in  the  process 
model. 
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STEP  3:  ANALYSIS  AND  MODELING  OF  THE  PROCESS  I/O 
AND  STORAGE  REQUIREMENTS 

A Basic  Process  Constructor  program,  called  the  I/O  and  Storage  Analyzer  (IOSA), 
analyzes  the  contents  of  the  Computer-Dependent  Model  File  to  retrieve  and  organize  the 
information  to  accomplish  the  program  loading/linking  and  I/O  control  functions.  Since  the 
hardware  assignments  are  not  yet  known  at  this  point,  the  information  to  be  produced 
essentially  (a)  describes  the  logical  communication  between  process  modules  through  subprogram 
calls  and  I/O  messages  and  (b)  summarizes  storage  requirements  for  program  linking/loading 
purposes.  Specifically,  the  IOSA  produces  information  on: 

All  three  types  (external,  interprogram,  and  intraprogram)  of  I/O  messages 
The  storage  space  needed  for  the  I/O  message  data  sets  and  buffers 
Temporary  working  storage  (scratch  memory  areas)  used  by  individual  tasks 
The  task  permanent  memory  requirements 

Standard  subroutines  called  by  each  task-a  separate  list  for  each  task  and  the 
resulting  temporary  storage  requirements  per  program. 

Information  on  all  three  types  of  I/O  messages  is  pooled  together  for  all  programs  in  the 
process  model  and  written  on  the  I/O  Description  File,  where  each  I/O  message  in  the  model  is 
described  in  terms  of  its  assigned  ID,  short  descriptor  in  English,  size,  production  rate,  producer, 
and  all  consumers.  In  addition,  a communication  link  matrix  describing  the  interprogram 
communications  and  a similar  matrix  describing  the  intraprogram-intertask  communications,  one 
for  each  program  in  the  process  model,  are  generated  and  written  on  the  same  file. 

Information  on  the  storage  requirements  for  programs  and  for  the  individual  tasks  which 
constitute  these  programs  shall  be  stored  on  the  Loader  Input  File.  The  following  information 
for  each  modeled  program  shall  be  contained  in  this  file: 

Permanent  storage  required  by  each  task  in  the  program 
Temporary  working  storage  required  by  each  task  in  the  program 

The  list  of  all  standard  subroutines  called  by  the  tasks  of  the  program  and  the 
storage  needed  for  each. 

Finally,  the  I/O  and  Storage  Analyzer  prints  a report  to  summarize  and  document  the 
information  stored  on  both  files. 

STEP  4:  ANALYSIS  OF  PROCESS  DECOMPOSITION 

For  each  program  in  the  process  model,  a computerized  algorithm  of  Basic  Process 
Constructor,  called  the  Process  Analysis  Program  (PAP),  first  analyzes  the  program  graph  to  do 
the  following:  (1)  validate  the  structural  correctness  of  program  graph,  (2)  construct  and  list  all 
alternative  execution  paths  through  the  program,  (3)  using  the  task  timing  information  from 
Step  2,  compute  the  expected  minimum  and  maximum  path  execution  times  for  each  path;  in 
addition,  if  the  program  graph  contains  information  on  branching  probabilities  (or  logical 
conditions),  the  PAP  computes  path  probabilities  (or  logical  expressions  determining  the  path 
selection). 


415 


MtppiM 


Next,  the  PAP  constructs  a synthetic  model  of  the  program.  The  following  input 
information  is  used  for  that  purpose:  (t)  the  computer-independent  program  model  from  Step  1, 
and  (2)  the  list  of  all  alternative  execution  paths  through  the  program.  Usmg  the  task  timing 
information  from  Step  3.  the  PAP  computes  the  expected  minimum  and  maximum  path 
execution  times  for  each  path.  If  the  program  graph  contains  information  on  branching 
probabilities  or  logical  conditions,  the  PAP  also  computes  the  path  probabilities  or  logical 
expressions  to  model  branching  during  simulation. 

The  synthetic  model  shall  define  a program  in  terms  of  (1 ) program  ID,  (2)  program  graph. 
(3)  description  and  timing  of  alternative  execution  paths,  (4)  storage  requirements,  (5)  message 
type  IDs  for  all  the  I/O  messages  consumed  or  produced  by  the  program,  and  (6)  expected 
execution  rates  and  other  control  information  needed  by  the  DP/M  executive.  In  addition,  each 
task  of  the  program  shall  be  described  individually  as  much  as  the  level  of  modeling  requires 
doing  so. 

The  PAP  shall  produce  the  following  analysis  outputs  for  each  processed  program  model: 

(1)  A printed  report  on  the  validation  of  structural  correctness  of  program  graph 

(2)  A printed  report  on  (a)  the  alternative  execution  paths  through  the  program  graph 
by  specifying  each  path  in  terms  of  an  ordered  node  (task)  list,  execution 
probability  (or  logical  conditions),  and  minimum  and  maximum  run  time  estimates, 
ib)  the  synthetic  model  of  the  program,  including  the  estimated  demands  on 
hardware  resources  (timing  and  storage) 

(3)  A punched  card  image  v ion  of  the  synthetic  model,  which  is  to  be  stored  in  a 
form  directly  acceptable  b>  the  simulator  as  Program  Synthetic  Model  File. 

STEP  5:  EVALUATION  OF  PROCESS  DECOMPOSITION 

In  the  BPC,  this  step  shall  be  carried  out  manually.  Using  the  output  information 
produced  in  Step  4,  :he  process  designer  analyzes  the  model  of  each  program  to  determine 
whether  the  program  does  not  exceed  the  processing-time  and  storage  limitations  of  hardware. 
The  required  program  iteration  rates  and  the  portion  of  real-time  that  can  be  allocated  to  the 
program  are  taken  into  account  to  decide  whether  the  timing  constraints  will  remain  unviolated. 
If  no  program  violates  the  hardware  limitations,  the  process  is  correctly  decomposed,  and  the 
process  construction  procedure  can  continue  to  Step  6;  otherwise,  it  must  return  to  Step  1 . or  to 
that  phase  of  process  development  which  precedes  Step  1 of  process  construction,  in  order  to 
re-partition  into  programs  an  appropriate  portion  of  the  process. 

The  conclusion  that  the  process  decomposition  is  incorrect  means  that  at  least  one 
program  in  the  process  model  exceeds  either  the  real-time  processing  constraints  or  the  memory 
capacity  of  a single  DP/M  Processing  Element.  Several  alternative  options,  depending  on  the 
cause  of  the  difficulties,  are  now  open  to  the  process  designer: 

Split  each  violating  program  into  several  new  programs,  each  satisfying  all  required 
real-time  and  hardware  constraints;  for  that  putpose.  use  the  maximally 
parallel  predecessor-successor  graph  of  the  violating  program,  obtained  in 
Step  I,  to  determine  the  best  program  partitioning;  the  optimality  criteria  that 
may  now  be  used  are.  for  example,  minimization  of  the  number  of  splits  (or 
of  new  programs!  and/or  minimization  of  the  resulting  longest  executior  path; 
the  second  criterion  implies  use  of  the  possible  parallelisms  indicated  in  the 
maximally  parallel  predecessor-successor  graph  of  the  original  program; 
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Modify  the  logical  partitioning  of  the  process  into  avionics  subfunctions,  which 
technically  precedes  Step  1 of  process  construction,  and  decompose  each 
subfunction  leading  to  a violating  program  into  several  subfunctions. 

The  second  approach  in  general  will  lead  to  a larger  perturbation  in  the  original  process 
partitioning  than  the  first;  what  is  even  worse  from  the  managerial  viewpoint  is  that  it  leads  to 
steps  that  precede  the  process  construction  Therefore,  the  first  approach  is  recommended; 
however,  if  the  structure  of  program  does  not  possess  enough  potential  parallelism,  the  sec  d 
approach  may  be  unavoidable  in  the  case  of  timing-constraint  violations. 

STEP  6:  PROCESS  SYNTHESIS:  ALLOCATION  OF  HARDWARE  RESOURCES 

A computerized  Basic  Process  Constructor  algorithm,  called  Hardware-Resource  Allocation 
Algorithm  (HRAA),  shall  be  used  to  assign  hardware  resources  to  the  programs  in  process  model 
and  to  determine  tl  best  hardware  configuration.  The  synthetic  models  of  process  programs, 
produced  in  Step  4,  and  the  I/O  Description  File  from  Step  3,  provide  the  input  information 
needed  by  this  algorithm. 

The  hardware  resource  assignment  is  to  be  optimal  in  the  sense  that  it  must  try  to 
minimize  the  potential  real-time  traffic,  or  interaction,  across  the  natural  boundaries  of  hardware 
units.  In  the  present  context,  the  in  ,;vidua!  Processing  Elements  of  a DP/M  system  represent 
such  hardware  units.  (Note  that  this  optimization  problem  is  equivalent  to  the  problem  of 
minimizing  the  required  hardware  resources.)  The  HRAA  shall  be  designed  to  permit  the 
mapping  of  a subset  of  proven  programs  into  the  pre-specified  PEs  of  DP/M.  with  the  remaining 
programs  to  be  mapped  optimally.  It  shall  produce  the  following  outputs: 

A printed  report  showing  the  resulting  hardware  configurafion.  the  PE  assignments 
to  programs,  and  the  projected  bus  traffic  and  Processing  Element  loads 

A summary  of  the  hardware  configuration  and  PF.  assignments  to  programs  which  is 
| to  be  added  to  the  Loader  Input  File. 

The  process  construction  procedure  shall  permit  the  process  designer  to  overrule  the 
hardware  resource  assignments  made  by  the  computerized  HRAA.  To  assist  the  process  designer 
m this  task,  a printed  report  (the  first  item  immediately  above)  shall  be  provided.  After 
examining  the  report,  the  process  designer  shall  be  able  to  choose  between  the  two  courses  of 
action:  (a)  to  have  further  modifications  made  by  changing  the  hardware  configuration  or  the 
program-to-PEs  assignments  and  then  by  executing  the  HRAA  or  (b)  to  proceed  to  Step  7. 

STEP  7:  GENERATION  OF  I/O  CONTROL  DATA 

A Basic  Process  Constructor  program,  called  I/O  Control  Data  Generator  (10CDG). 
combines  the  results  of  the  hardware  resource  assignments  (made  in  Step  6 and  stored  in  the 
I Loader  Input  File)  with  the  model  of  the  I/O  interaction  between  process  modules  (constructed 

in  Step  3 and  stored  in  the  I/O  Description  File)  to  generate  the  control  data  for  handling  the 
process  I/O  in  simulated  real-time.  For  system  network  or  functional  simulation,  the  I/O  control 
1 data  describes  each  type  of  I/O  message  in  terms  of  its  ID.  size,  producer,  consumers,  scheduling 

rules,  and  hardware  routing  information. 

t This  program  shall  produce  the  following  outputs: 

| A printed  report  describing  the  routing,  timing,  and  scheduling  control  of  the 

r external,  bus  (interprocessor),  and  intraprocessor-interprogram  I/O  messages 
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A data  file  (punched  card  images),  called  the  I/O  Control  Data  File,  containing  the 
description  of  the  process  I/O  and  all  additional  information  that  is  needed  to 
control  the  I/O  traffic  in  DP/M  simulators  (all  data  on  the  I/O  Control  Data 
File  shall  be  formatted  to  be  directly  input  into  the  simulators). 

STEP  8:  GENERATION  OF  PROGRAM  EXECUTION  CONTROL  DATA 

A Basic  Process  Constructor  program,  called  Program  Execution  Control  Data  Generator 
(ECDG),  shall  pool  together  and  edit  all  data  needed  to: 

Initialize  the  process  in  simulated  real-time 

Control  the  simulated  execution  of  programs 

The  inputs  to  this  step  come  from: 

The  program  Synthetic  Model  File 

The  Loader  Input  File 

The  output  data  shall  be  organized  and  formatted  to  represent  the  actual  tables  and  lists 
used  by  the  simulation  models  of  DP/M  Executives.  The  information  contained  in  the  output 
data  shall  describe  each  process  program  by  its  ID,  scheduling  and  prion.,  rules,  program  input 
and  output,  running  time  estimates  for  individual  tasks,  the  maximally  parallel  predecessor- 
successor  graph,  and  the  hardware  assignments  made  in  Step  6.  Every  task  belonging  to  a 
program  shall  be  defined,  as  much  as  the  level  of  modeling  requires  doing  it,  in  similar  tenns.  To 
facilitate  simulation,  the  output  shall  also  describe  all  alternative  execution  paths  through  the 
program  graph,  where  each  path  is  specified  by  an  ordered  list  of  tasks  (nodes  in  the  program 
graph),  task  transition  probabilities,  and  task  execution  times.  All  outputs  shall  be  stored  on  the 
Program  Execution  Control  Data  File,  the  information  on  which  will  be  organized  and  structured 
to  be  directly  usable  by  the  simulators:  they  shall  also  appear  as  a printed  report. 

STEP  9:  PROCESS  LINKING/LOADING  AND  GENERATION  OF 
A SYSTEM  CONFIGURATION  DOCUMENT 

In  construction  of  an  actual  process  for  the  target  DP/M  system,  the  first  function  of  this 
step  represents  linking  and  loading  of  the  process  data  and  software.  For  that  purpose,  one 
would  use  a special  linking  loader.  In  construction  of  process  models  for  simulation,  this  step 
reduces  itself  to  the  allocation  of  simulated  storage  and  generation  of  memory  maps.  A Basic 
Process  Constructor  program,  called  Process  Loader,  shall  use  the  information  on  storage 
requirements,  stored  on  the  Loader  Input  File,  to  construct  memory  maps  for  each  Processing 
Element.  These  maps  serve  a two-fold  purpose: 

They  allow  to  study  in  detail  certain  hardware  and  software  design  problems 

lTiey  are  actually  needed  for  functional  (but  not  for  system  network)  simulation. 

The  second  function  of  this  step  is  to  produce  a system  configuration  document.  This 
document  shall  consist  of  two  master  directories.  The  first  directory,  to  be  called  the  Software 
Module  Master  Directory,  shall  list  and  describe  all  software  modules  in  the  process  which  are  to 
be  loaded  independently  (i.e.,  those  which  are  considered  to  be  external  modules  with  regard  to 
program  loading  functions).  The  other  directory,  to  be  called  Data  Set  Master  Directory,  shall 
describe  all  defined  data  sets  (i.e.,  arrays,  buffer  events,  file  space)  for  which  the  memory  is  to 
be  allocated  independently.  The  entries  in  both  directories  shall  indicate  the  PE  assignments 
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made  in  Step  6.  The  outputs  of  the  Process  Loader  shall  be  written  into  the  Process  Memory 
Map  and  System  Configuration  File;  they  shall  also  appear  in  the  form  of  a printed  report. 

6.  Process  Construction  Algorithms  and  Input/Output  Data  Sets 


The  purpose  of  this  subsection  is  to  specify  the  key  algorithms  and  major  input/output 
data  sets  (files)  for  the  Basic  Process  Constructor.  The  key  algorithms  are  specified  by  associating 
the  steps  of  the  process  construction  procedure,  outlined  in  Subsection  IX.C.5,  with  various 
algorithms  discussed  in  Subsection  1X.B. 5.  To  avoid  repetition  these  algorithms  are  not 
completely  restated  in  the  sequel.  Algorithms  of  only  two  types  are  specified;  those  to  be  used 
for  process  analysis,  and  those  for  process  design.  As  pointed  out  in  the  beginning  of  Subsection 
IX.B.5,  the  algorithms  which  have  not  been  specified  in  this  document  are  data  transformation 
algorithms:  They  are  not  only  relatively  simple  but  also  depend  on  the  detailed  design  of  the 
data  sets  of  the  BPC.  After  the  detailed  design  of  the  data  sets  becomes  available,  these 
algorithms  can  be  designed  in  a straight-forward  fashion  from  their  high-level,  functional 
descriptions  given  in  Subsection  1X.B.5,  and  from  the  data  set  specifications. 

In  order  no  to  restrict  the  software  design  and  implementation  alternatives  for  the  BPC, 
only  the  exogenous  input,  endogenous,  and  certain  intermediate  (i.e.,  those  to  be  used  to 
interface  with  the  (.rocess  designer)  output  data  sets  of  the  process  construction  procedure  are 
specified  here;  the  others  can  be  designed  in  many  different  ways  by  using  the  functional 
overview  given  in  Subsection  IX.C.5  as  a guideline. 

a.  Process  Construction  Algorithms 

STEP  1;  GENERATION  OF  A COMPUTER-INDEPENDENT  PROCESS  MODEL 


Two  process  analysis  algorithms  are  used  in  this  step: 

An  algorithm  which  for  each  program  in  the  process  model  generates  the  maximally- 
parallel  predecessor-successor  graph  with  the  following  two  properties: 

(a)  The  graph  guarantees  program  execution  determinacy 

(b)  It  is  of  minimum  complexity  (has  the  least  number  of  links)  among  all 
maximally -parallel  determinate  graphs. 

In  the  present  context,  the  program  execution  determinacy  means  that  the  actual 
order  of  execution  of  the  tasks  which  belong  to  a group  of  conjunctive  parallel 
paths  does  not  affect  the  results  of  computation. 

Such  a graph  can  be  constructed  by  analyzing  the  input/output  relationships 
between  the  tasks  of  a graph  (these  tasks  constitute  the  nodes  of  the  graph).  A 
technique  for  constructing  the  maximally  parallel  predecessor-successor  graph  of  a 
program  is  outlined  in  reference  fill. 

An  algorithm  for  constructing  the  program  graph,  which  shows  all  alternative  (i.e.. 
disjunctive)  execution  paths  through  the  program;  once  the  maximally  parallel 
predecessor-successor  graph  is  available,  the  program  graph  can  be  derived  fiom  the 
forme,  by  stringing  out  the  paths  of  every  conjunctive  group  of  parallel  path,  in  an 
arbitrary  sequential  order. 
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STEP  2:  GENERATION  OF  A COMPUTER  DEPENDENT  PROCESS  MODI  L 

All  algorithms  are  data-transformation  and  reduction  procedures 

STEP  3:  ANALYSIS  AND  MODELING  OF  THE  PROC  ESS  i/O  AND 
STORAGE  REQUIREMENTS 

All  algorithms  are  data-transformation  and  reduction  procedures. 

STEP  4:  ANALYSIS  OF  PROC  ESS  DECOMPOSITION 

Algorithms  for  the  following  analysis  functions  are  required- 

Construction  of  the  Transition  Probability  Matrix.  T.  (or  ol  a similar  matrix  which 
would  specify  the  logical  branching  conditions  in  selection  ot  alternative 
program  execution  paths). 

Construction  of  Node  Adjacency  matrix  from  the  program  graph 
Topological  ordering  of  the  nodes  in  the  program  graph 
Generation  of  Path  Matrix 

Generation  (enumeration)  of  ail  feasible  execution  paths  by  listing  in  proper  order 
the  nodes  of  each  path 

Computation  of  the  path  timing  estimates  and  probabilities 
Computation  ot  memory  requirements. 

The  topological  sort  based  on  Fulkerson's  Rule,  which  has  been  referred  to  as  Algorithm  1 
in  Subsection  IX.B.5  shall  be  used  to  accomplish  the  third  function  above 

Foi  the  fourth  function  (i.e..  construction  of  a Path  Matrix).  Warchall's  Algorithm,  known 
as  Algorithm  2 in  Subsection  IX.B.5.  shall  be  used. 

Algorithm  3 of  Subsection  IX.B.5  shall  be  used  to  genciute  all  alternative  execution  paths 
through  the  program- 

AH  other  functions  in  this  step  constitute  simple  data  analysis  reduction  procedures 

STEP  5:  EVALUATION  OF  PROCESS  DECOMPOSITION 

It  is  a human  decision  task  The  decision  whether  to  consider  the  process  as  being 
correctly  decomposed  or  not  is  to  be  made  on  the  basis  of  the  information  contained  in  two 
printed  reports  produced  in  Step  4.  one  on  the  correctness  of  program  structure  and  the  other, 
on  program  synthetic  models. 

STEPb:  ALLOCATION  OF  HARDWARE  RESOURCES 

This  step  is  a two-stage  iterative  procedure  in  .."Inch  the  process  designer  is  m a loop  with 
a computerized  (sub)optimal  hardware  resource  allocation  algorithm  As  stated  previously,  the 
two  mam  tunclions  of  this  algorithm  are 
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To  assign  PEs  to  the  programs  constituting  a process  such  'hat. 

Ail  reai-tn  e and  storage  constraints  are  satisfied 

The  total  bus  traffic  due  to  the  interprogram  communications  is  minimized 

To  derive  ’he  corresponding  hardware  contiguration  requirements  which  would 
specify: 

The  total  number  of  PEs  needed 

All  PEs  which  are  to  he  connected  to  external  sources  or  sinks  and  into  which 
appropriate  External  I'O  Handlers  (programs)  are  to  he  placed. 

As  stated  in  Subsection  IX.B.5.  four  candidate  algorithms  have  been  considered  for 
(sub)opttmal  hardware  resource  allocation.  The  results  ot  the  investigation  ot  these  algorithms 
indicate  that  either  Algorithm  4A  (the  Branch  and  Bound  method  ot  linear  integer  programming) 
or  Algorithm  4B  (MacQueen’s  K-Means  Method*  hould  he  the  linal  choice  Algorithm  4A  should 
be  selected  *f  the  optimality  of  allocation,  m not  its  computational  cost.  is  the  primary 
consideration:  Algorithm  4B  should  he  selected  it  (he  cost  ot  computation  and  limitations  ot  the 
developmental  computer  are  important. 

STL.  7.  (GENERATION  OF  I O CONTROL  DATA).  H (GENERATION  OF 
PROGRAM  EXECUTION  CONTROL  D.ATU  and  *»  (PROCESS 
LINKING  AND  LOADING i 

These  steps  involve  only  data  transformation  and  reduction  procedures  The  main  function 
of  the  procedu *e  constituting  Step*)  is  storage  allocation  for  evr  PI  in  the  determined  DP  M 
configuration  storage  is  to  he  allocated  tor  both  the  programs  jnd  data  sets  buffer  according  to 
the  hardware  allocations  made  in  Step  ft. 

h.  Data  Sets  of  the  Basic  Process  Constructor 

The  following  files  reports  ot  the  Basic  Process  Constructor  have  been  identified  and  are 
described  in  Appendix  A 

Input  data  sets  and  input  documentation  reports 

Computer-Independent  Model  ol  the  Process  (Input  File) 

Report  on  ( omputer-lndependent  Model  ot  the  Process 
Computer  Hardware  Delmitioti  (Input  Filet 
Report  on  Compu'er  Hardware  IX-timtion 
Process  construction  endogenous  outputs 
LO  Control  Data  File 
Repoit  on  I O Message  Routing 
Program  Execution  Control  Data  File 
Report  on  Program  I xceution  Contiol 
Memory  Map  and  System  Contiguration  File 
Report  on  Memory  Maps  and  System  Configuration 
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Intermediate  output  reports 

Report  on  the  Correctness  of  Program  Structure 

Report  on  Program  Synthetic  Models 

Report  on  Hardware  Configuration  and  Assignments. 

The  output  reports  Isited  above  under  the  third  category  are  those  intermediate  reports  by  means 
of  which  the  designer  interfaces  with  the  process  construction  procedure.  Their  mam  function  is 
to  keep  the  designer  informed  about  the  progress  and  partial  results  of  process  construction  at 
two  critical  stages  of  the  process  construction  procedures:  the  process  decomposition  analysis 
• Steps  4 and  5)  and  the  hardware  resource  allocation  (Step  6). 

7.  implementational  Requirements 

This  subsection  summarizes  the  implementational  requirements  of  the  Basic  Process 
Constructor.  Since  there  is  no  intent  at  the  present  time  to  foreclose  on  any  of  the  significant 
design  and  implementation  alternatives  or  to  dictate  the  selection  of  the  developmental  host 
computer,  the  implementational  requirements  have  been  reduced  to  a summary  of  the  projected 
minimal  processing  capability  requirements  for  the  developmental  host  computer  system.  These 
capability  projections  have  been  derived  from  the  assumption  that  the  same  host  computer  will 
be  used  for  the  following  functions: 

Process  construction  under  the  Basic  Process  Constructor 

All  basic  types  of  process  and  hardware  simulations  (system  network,  functional, 
instruction  level) 

Development  of  the  support  software 

Process  Development  Information  System  operations 

Compilation  of  DP/M  programs  to  be  simulated  by  the  instruction  level  simulator  or 
executed  on  a DP'M  system. 

a.  Software  and  Support  Function  Requirements 

The  developmental  host  computer  shall  be  provided  with  and/or  shall  be  capable  of 
supporting. 

Ihe  high  level  programming  language(s)  in  which  the  Basic  Process  Constructor, 
simulation  software,  the  utility  subroutines  of  Process  Development 
Information  System,  and  other  support  programs  are  to  be  coded 

Compiler  for  the  high-level  programming  language  of  the  DP/V.  system 

So f* "'are  facilities  needed  to  accomplish  the  Program  Library  functions  of  the 
Process  Development  Information  System  (these  functions  comprise  the 
st  mdard  operations  used  in  handling  the  partitioned  source  and  object  >.  ode 
libraries). 

It  there  is  no  intent  to  use  the  host  computer  o’  the  Basic  Process  Constructor  tor  the 
development  of  sottware  for  DP,  M systems,  the  second  requirement  listed  above  may  be 
ielinqutshed. 


b.  Hardware  Requirements 


The  following  features/characteristics  of  the  host  computer  hardware  represent  the 
projected  minimal  hardware  capability  requirements: 

At  least  an  equivalent  of  100K  32-bit  words  of  central  memory  available  to  the  user 

At  least  10  million  32-bit  words  worth  of  disk  storage 

At  least  one  80-column  (or  wider)  line  printer 

At  least  one  card  reader 

At  least  one  card  punch 

At  least  one  magnetic  tape  drive. 

0.  PROCESS  CONSTRUCTION  CASE  STUDY 

To  evaluate  the  fundamental  steps  involved  in  the  basic  process  construction  methodology, 
a case  study  involving  computerized  and  manual  procedures  was  performed.  The  effort  involved 
the  allocation  of  a network  of  DP/M  PEs  to  a set  of  avionic  processing  functions  for  a 
hypothetical  mission.  The  mission  and  functions  selected  were  similar  to  a Gose  Air  Support 
mission  and  the  processing  functions  were  those  associated  with  a NARBS  (Night  Anple  Rate 
Bombing)  mode.  Three  sets  of  data  were  formed.  An  existing  data  base  of  avionics  functions  that 
was  described  in  terms  of  basic  operations  (t.e.,  number  of  additions,  subtractions,  multiplies, 
divides,  logical  operations,  sines,  cosines,  etc.)  was  used  as  the  computer-independent  description 
of  each  of  the  processing  algorithms.  A model  description  of  the  DP/M  PE  computational 
characteristics  (i.e.,  operation  execution  times  and  memory  allocations)  was  defined.  A third  data 
set  was  made  up  of  the  input/output  variables  associated  with  the  avionic  functions.  The  I/O 
data  served  as  a basis  for  the  generation  of  three  reports.  The  most  fundamental  I/O  data  report 
was  an  alphabetized  listing  of  all  signals  in  the  system.  The  second  report  showed  each  I/O  signal 
and  the  consumers  (avionic  programs)  of  the  signal.  The  final  report  listed  each  avionics  program 
and  its  input  and  output  variables.  The  program  input  variables  were  grouped  according  to  the 
source  of  the  signals  to  give  a first  cut  indication  of  likely  collections  of  variables  for  bus 
messages. 

The  avionic  program  (or  subfunction)  input/output  data  was  combined  with  the  computer 
algorithm  independent  operation  summary,  and  this  information  was  used  by  a series  of 
computer  programs  to  automatically  calculate  the  execution  time  and  memory  allocation  require- 
ments for  the  avionics  subfunction  with  respect  to  the  DP/M  PE  model.  An  output  report  was 
generated,  summarizing  the  memory,  timing,  and  input/output  requirements  for  each 
subfunction,  plus  a set  of  summary  records  (punched  cards).  These  summary  records  were 
processed  by  a task  analysis  program  to  verify  the  structural  corrections  of  the  avionic 
subfunction  directed  graph,  to  analyze  the  number  of  transitional  execution  paths  through  the 
program  based  on  assigned  probability,  and  to  give  an  estimate  of  processor  execution  time 
loading  for  the  given  avionics  subfunction.  This  information  was  used  for  the  manual  resource 
allocation  of  avionic  functions  to  DP/M  PEs. 

Following  the  manual  resource  allocation  process,  a system  network  simulation  was  made 
of  this  hypothetical  mission  and  performance  reports  gathered  for  a sample  time  interval. 
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1.  Mission  Segment  Description  Summary 
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The  chosen  CAS  NARBS  mode  mission  segment  was  made  up  of  a number  of  active 
processing  programs  that  are  summarized  along  with  their  respective  iteration  rates  in  Table  34. 


TA1LC  34.  CLOSE  AIR  SUPPORT  MISSION /ATTACK 
SEGMENT-NAR1S  MODE  PROGRAM  SUMMARY 

ttentioa 

Propam  Rate/Sec 


A1RDATA/AIRDATASS 

16 

CONPANSS 

16 

CNPANMAN 

1 

DISPLMAN 

4 

D1SPLASS 

4 

FLTCONT/FLTCONSS 

64 

MISSMGT 

1 

NAVF1LT 

1/8 

RADARSS 

32 

RADALTiiS 

32 

ECMSS 

32 

COMMSS 

16 

AIRCRFSS 

2 

GYRACESS 

32 

STOMANSS 

32 

1NSNAV/INSSS 

32 

DOPPLER/DOPPSS 

32 

LORAN/LORANSS 

32 

RHAWGTL 

32 

FURPTG/FURSS 

32 

NARBSWD 

32 

2.  Mission  Software  Models 

Each  of  the  active  mission  processing  programs  was  described  in  terms  ot  a directed  graph 
along  with  each  node  (or  task)  within  the  graph.  A summary  of  this  description  is  shown  by  the 
reports  given  in  Figures  172  and  173.  This  generic  description  of  the  computer  operations  for 
each  program  task  was  derived  from  the  math  and  logic  algorithms  used  for  each  avionics 
function.  A summary  of  the  usage  of  these  generic  operations  per  application  program  is  given  in 
Table  35.  Also  included  in  the  description  of  each  program  node  is  its  iteration  rate,  subprograms 
called,  input/output  variables,  and  a list  of  candidate  successor  tasks  and  the  transitional 
probability  for  each  successor  task. 
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SYNTHETIC  MODEL  OF  A PROGRAM 


01/08/75 


PROGRAM  NAME  AIROATA 

PROGRAM  10  NUMBER  1 


FOR  COMPUTER  WHOSE  ID  IS  DP/M  PE 


NAME  OF  THE  INITIAL  PROCEDURE 
NUMBER  OF  PROCEDURES 

PTCN 

4 

PERIODICITY  (• NUMBER  OF  REPETITIONS 

PER  MAJOR  CYCLE) 

16 

NUMBER  OF  INPUTS 

9 

NUMBER  OF  OUTPUTS 

*•«•**•**«*••** •*••«**•****< 

12 

Figure  172.  ftapam  Synthetic  Model  Snuunvy  Report 


3.  Computer  Definition  Model 

In  conjunction  with  the  computer-independent  model  descriptions  of  the  avionic 
processing  functions,  a computer-dependent  model  of  the  DP/M  Processing  Element  was  defined. 
This  PE  model  description  was  based  upon  conservative  estimates  of  instruction  execution  times. 
Math  subroutine  execution  times  are  representative  of  those  functions  on  current  airborne 
minicomputers.  A summary  of  the  DP/M  PE  hardware  model  used  in  the  case  study  is  given  in 
Figure  174. 

4.  Application  Program  Timing  and  Sizing  Effort 

A task  analysis  program  was  used  to  process  the  avionic  program  description  and  PE 
computer  model  description  and  to  produce  a series  of  reports  summarizing  program  execution 
paths,  processor  loading  and  memory  requirements  for  the  program.  Figure  1 75  shows  the  report 
generated  for  one  of  the  case  study  avionic  programs  whose  program  graph  is  shown  in 
Figure  176. 

With  the  given  avionic  program  description  and  computer  model  used  for  this  sizing  effort, 
the  following  observations  were  made: 

( 1 ) The  processor  loading  for  each  application  program  wa;  such  that  it  would  have  no 
difficulty  being  processed  in  only  one  PE. 

(2)  Memory  resources  requirements  of  each  application  program  were  small  enough  to 
fit  into  a 4K  memory  in  the  majority  of  cases. 
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01/08/75 

SYNTHETIC  MODEL  OF  A PROCEDURE 

PROCEDURE  NAME  PTCN 

ID  NO.  101 

COUNT  FOR  PROGRAM  AIROATA  1 


PERMANENT  MEMORY  ( 16-01 T WORDS)  SOS 

TEMPORARY  MEMORY  (16-8 IT  WORDS)  61 

REPETITIONS  (LOOPS) 

MINIMUM  NUMBER  1 

MAXIMUM  NUMBER  1 

RUNNING  TIME  PER  REPETITION  (MICROS Er~ONOS I 

MINIMUM  2S67.S0C 

MAXIMUM  2571. S00 

NUMBER  OF  SUBROUTINE  PROCEDURES  CALLED  0 

NUMBER  OF  INPUT  VARIABLES  USED  9 

NUMBER  OF  OUTPUT  VARIABLES  PRODUCED  12 

NUMBER  OF  PROCEDURE  SUCCESSORS  1 


PROCESSING  LOAD  PER  REPETITITON  (ITERATION) 

SINGLE  PRECISION  ARITHMETIC  OPERATIONS 

AOOITIONS/S'lBTR  ACTIONS  12 

MULTIPLICATIONS  23 

DIVISIONS  6 

DOJBLE  PRECISION  ARITHMETIC  OPERATIONS 

AODIT IONS/ SUBTRACT IONS  0 

MULTIPLICATIONS  0 

DIVISIONS  0 

LOGIC AL/BOOLEAN  OPERATIONS  0 

AVG.  NO.  OF  CONTROL  QPERNS  PER  ONE  ARITH  OPERN  7.0 

AVG.  NO.  OF  CONTROL  OPERNS  PER  ONE  LOGIC  OPERN  3.0 

SINGLE  PRECISION  STANDARO  SUBROUTINE  CALLS 

SQUARE  ROOT  5 

SINE/COSINE  0 

ARC TAN  0 

EXPONENTIAL  0 

LOGARITHM  6 

ARCSIN/ARCCOS  0 

DOUBLE  PRECISION  STANDARD  SUBROUTINE  CALLS 

SQUARE  ROOT  0 

SINE/COSINE  0 

ARC TAN  0 

EXPONENTIAL  0 

LOGARITHM  0 

ARCSIN/ARCCOS  0 

Figure  173.  Talk  Synthetic  Model  Summary  Report  (Sheet  I of  2) 
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LIST  OF  INPUT  VARIABLES  REQUIRED 

BV  PROCEDURE  PTCN 


TYPE 

VAR 

VARIABLE  NAME 

VARIABLE 

SOURCE 

ITER 

BITS 

to 

ABREV'N 

RATE 

P 

l 

IND  TEMP 

T I 

ADSENS 

2 

12 

P 

I 

IND  ANG  ATTK 

AOA  I 

AOSENS 

8 

12 

P 

1 

IND  STAT  PRES 

PS  I 

ADSENS 

16 

16 

P 

1 

IND  TOT  PRES 

PTl 

ADSENS 

16 

16 

P 

1 

TOT  PRES  STATUS 

SIOI 

AIPDATSS 

1 

1 

P 

1 

STAT  PRES  STATUS 

S 102 

AIRDATSS 

1 

1 

P 

1 

TEMP  STATUS 

S103 

AIROATSS 

i 

l 

P 

1 

AOA  STATUS 

SI  04 

AIRDATSS 

1 

1 

P 

1 

SCALES  UP  STATUS 

S290I 

CONPANSS 

16 

1 

LIST  OF  OUTPUT  VARIABLES  PRODUCED 

BY  PROCEDURE  PTCN 


TYPE 

VAR 

ID 

VARIABLE  NAME 

VARIABLE 

ABREV'N 

ITER 

RATE 

BITS 

P 

l 

MUD  SCL  VTAS 

C101 

16 

10 

P 

1 

HUO  SCL  ALT 

C102 

16 

10 

P 

1 

HUO/BASE/VEL 

YlOl 

16 

10 

P 

1 

HUO/BASE/ALT 

Y102 

16 

10 

P 

1 

HUD/TMERM  SCL  IT 

Y103 

16 

10 

P 

l 

MUD/THERM  SCL  RT 

Y 104 

16 

10 

P 

1 

ANG  OF  ATTK 

AOA 

16 

16 

P 

1 

SIDESLIP  ANGLE 

BETA 

16 

16 

P 

1 

8AR0  ALT 

MB 

16 

16 

P 

1 

AIR  OENSITY 

RHO 

16 

16 

P 

l 

INO  AIRSPEED 

VC 

16 

16 

P 

1 

TRUE  AIRSPEED 

VTAS 

16 

16 

************************************************************* 

SUCCESSORS  OF  PROCEDURE  PTCN 


SUCCESSOR 


NO. 

NAME 

ID  NO. 

TRANS. PROS 

1 

AOA 

102 

1.000 

**** ******* **************  ** 


? 


************************************************************* 

01/01/75 

COMPUTER  DEFINITION 


COMPUTER  10  NAME 

ADDITIONAL  IDENTIFICATION 


OP/M  PE 
PROTOTYP 


ALL  TIMING  DATA  IS  IN  MICROSECONDS 


MEMORY  SIZE  (16-BIT  WORDS) 


4096 


SPEED  OF  SINGLE  PRECISION  OPERATIONS 


ADD IT  ION/ SUBTRACT  ION 

- 

MIN 

T 

2.000 

- 

MAX 

T 

4.000 

MULTIPLICATION 

- 

MIN 

T 

20.000 

- 

MAX 

T 

20.000 

t 

01 VI  SION 

- 

MIN 

T 

20.000 

— 

MAX 

T 

20.000 

r 

SPEED  OF  OQUBLE  PRECISION  OPERATIONS 

ADDITION/SUBTRACTION 

• 

MIN 

T 

60.000 

/ 

- 

MAX 

T 

70.000 

MULTIPLICATION 

- 

MIN 

T 

250.000 

> ! 

- 

MAX 

T 

350.000 

; i 

01  VISION 

- 

MIN 

▼ 

• 

250.000 

: i 

• ! 

— 

MAX 

T 

350.000 

i 

LOGICAL/BOOLEAN  OPERNS-  AVG  T 

3.000 

• 

CONTROL  OPERNS  - AVG  T 

2.500 

SUBROUTINE  LINKAGE  - AVG  T 

4.000 

f 

I 


I 

L 


AVG  EXFC  T FOR  STANOARD  SINGLE 
SQUARE  ROOT 
SINE/COSINE 
ARC TAN 
EXPONENTIAL 
LOGARITHM 
ARCS  IN/ ARCCQS 


PRECISION  SUBROUTINES 

170.000 

115.000 

135.000 

215.000 

15.000 

300.000 


AVG  EXEC  T FOR  STANDARD  DOUBLE 
SQUARE  ROOT 
SINE /COSINE 
ARCTAN 
EXPONENTIAL 
LOGARITHM 
ARCSIN/ARCCOS 


PRECISION  SUBROUTINES 

4900.000 

1100.000 

1200.000 

1500.000 

1200.000 

6000.000 


MEMORY  ALLOCATION  GUIDELINES 


I SINGLE  PREC  ARITH  QPER'NS  - PERM  MEM  1.5 

- TEMP  MEM  0.5 

DOUBLE  PREC  ARITH  OPER'NS  - PERM  MEM  2.0 

- TEMP  MEM  1.0 

" LOG'L, CONTROL, SUB  LINK  - PERM  MEM  1.5 

f - TEMP  MEM  0.0 


Figure  174.  Computer  Definition  Model 
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OP/M  PROCESS  CONSTRUCT  ION 


DATE*  750116 


PROGRAM  MOOEL  REPORT  - PAGE: 

PROGRAM  NAME: 

ID  ** 

• OF  ITERATIONS  PER  SECOND: 


INSNAV 


0 

32 


f OP  NOOES:  10 

INPUTTED  10  # OF  ENTRY  NODE:  106 


COMPUTER  MODEL: 

#•*•******••****«*•*••****. 


DP/M  PRO»  ■-  TYPE 


NODE  NODE  TOPO  PERM  TEMP  MIN  MAX  MIN  RUN  MAX  RUN  IN-  SUCCESSOR 


ID# 

NAME 

ID# 

MEM. 

MEM. 

REP# 

REP# 

T(USECS) 

T(USECS) 

DEGR 

ID# 

T.PROB 

106 

IENT 

1 

96 

38 

1 

1 

168 

168 

0 

107 

0.0100 

108 

0.9800 

114 

0.0100 

107 

UNI 

2 

145 

5 

1 

1 

1508 

1512 

1 

108 

1.0000 

114 

I AMS 

3 

36 

0 

1 

1 

63 

63 

1 

115 

1.0000 

108 

I PLT 

4 

1273 

53 

1 

1 

3356 

3438 

2 

109 

0.3000 

110 

0.7000 

104 

INFC 

5 

204 

8 

1 

1 

332 

366 

1 

110 

1.0000 

110 

I NOT 

6 

120 

0 

5 

5 

210 

210 

2 

111 

1.0000 

111 

INAS 

7 

72 

0 

1 

1 

126 

126 

1 

112 

0.9800 

113 

0.0100 

115 

0.0100 

112 

I UNO 

8 

48 

2 

l 

1 

114 

118 

1 

113 

0.9900 

115 

0.0100 

113 

I HUD 

9 

0 

0 

1 

1 

0 

0 

2 

115 

1.0000 

115 

IENO 

10 

0 

0 

1 

1 

0 

0 

4 

A***************************** *••**•••*••**•******•••••••**•••**•****•*« 


Figure  175.  INSNAV  Sizing  Report  (Sheet  1 of  2) 


(3)  Allocation  of  programs  from  a resource  standpoint  would  have  to  be  made  based  on 
memory  required,  rather  than  processor  loading. 

It  should  be  noted  that  these  observations  were  applicable  for  the  description  data  base  of 
programs  used  for  the  case  study,  and  such  observations  are  not  intended  to  be  universal  in 
nature. 


5.  Partitioning  Results 


This  subsection  describes  the  results  of  the  nominal  allocation  of  application  programs  to 
DP/M  resources  based  on  the  output  of  the  Process  Constructor  and  the  location  of  the 
sensor/actuator  (if  any)  associated  with  each  application  program.  A system-level  flow  of  control 
and  messages  was  constructed  and  is  shown  in  Figure  1 77.  The  allocation  process  was  manual 
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OP/M  PROCESS  CONSTRUCTION 


OATES  750116 


PROGRAM  MODEL  REPORT  - PAGE:  2 


PROGRAM  NAMES 
10  «: 

# OF  ITERATIONS  PER  SECOND: 


INSNAV 


0 

32 


4 OF  NODES: 

INPUTTED  10  * OF  ENTRY  NODE: 


10 

106 


COMPUTER  MODEL:  DP/M  PROTOTYPE 

**•»•*•••**••«■**«*•***•*•*••*•**•***•••*••**•****** *****••*******•*•♦•*• 


4 OF  EXECUTION  PATHS 


17 


PATH 


4 

PROS 

MIN  RUN  T 

MAX  RUN  T 

PATH  DESCRIPTION 

l 0.00291 

6654.0 

6778.0 

106->107->108— >109— >110->1 11— >112— >113 

->1 15 

2 

0.01000 

231.0 

231.0 

106->1 14— >115 

3 

0.28524 

5146.0 

5266.0 

106— >1Q8->109— >110— >1 il->l 12— >1 13->115 

4 

0.00679 

6322.0 

6412.0 

106->107— >108— >110— >111->112->113— >115 

5 

0.66556 

4814.0 

4900.0 

106— > 1 08— > 1 lO-> 1 1 1— > 1 12-> l 1 3— > l 1 5 

6 

0.00003 

6540.0 

6660.0 

1 06— > 107-> 108- > 1 09— > 1 10-> 1 1 l-> 1 13->ll 5 

7 

0.00003 

6540.0 

6660.0 

1 06-> 1 07-> 1 08-> l 09-> 1 l 0-> 1 1 l-> 1 1 5 

8 

0.00294 

5032.0 

5148.0 

106— >108— >109— >110— >111— >1 13— >115 

9 

0.00294 

5032.0 

5148.0 

1 06->  1 08->  1 09->  1 10->  1 1 1->  1 1 5 

xO 

O.OOOC7 

6208.0 

6294.0 

1Q6->107->108— >1 10— >1 11->1 13->1 15 

11 

0.00007 

6208.0 

6294.0 

106— >107— >108— >1 10->H1->1 15 

12 

0.00686 

4700.0 

4782.0 

1 06- > 1 08-> l 1 0-> 1 1 l-> l 1 3-> 1 1 5 

13 

0.00686 

4700.0 

4782.0 

I06->108->110->111->115 

14 

0.00003 

6654.0 

6778.0 

1 06- > 1 07->  1 08->  1 09->  1 10->  1 1 1->  H2->  1 1 5 

15 

0. 00288 

5146.0 

5266.0 

1 06-> l 08-> 1 09-> 1 10-> 1 1 l-> 1 12-> l 1 5 

16 

0.00007 

6322.0 

6412.0 

1 06-> 10  7-> 1 08-> 1 10-> 1 1 1-> 1 12-> 1 1 5 

17 

0.00672 

4814.0 

4900.0 

1 06-> 1 08-> 1 10-> 1 1 l-> 1 12-> 1 1 5 

PROCESSOR  LOAOING  * 2.168960E-01  SECS/SEC  OR  * 21.69  X OF  CAPACIT\ 


MEMORY  OCCUPANCY 

PERMANENT  » 1996  16-BIT  WORDS 
TEMPORARY  * 53  16-BIT  WORDS 

»*****••**********•**•*******•*******••**•**••**•** *••*••*•**•*1 


Figure  17S.  INSNAV  Sizing  Report  (Sheet  2 of  2) 
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ENTER 


EXIT 


Figure  176.  Program  Graph  of  INSNAV  (Inertial  .'iaviption) 


and  resulted  at  most  in  a conservative  approach  to  allocating  application  programs  to  DP/M 
resources.  Table  36  represents  this  allocation.  The  avionics  subfunctions  which  the  application 
program  names  represent  are  shown  in  Table  37. 

6.  Simulation  Description 

This  subsection  describes  the  method  and  the  procedure  that  were  used  to  model  the 
results  of  process  construction  for  the  study  so  the  CAS  mission  could  be  simulated  on  the 
System  Network  Simulator  described  in  Section  VII.  Model  description  input  was  made  to  the 
System  Network  Simulator  consisting  of  data  pertaining  to:  (a)  bus  characteristics:  (b)  Global  bus 
connectivity  specification;  (c)  Local  bus  connectivity  specification;  (d)  task  definitions;  and 
(e)  definition  of  all  subfunctions  scheduled  by  the  Globai  Executive.  The  input  format  of  this 
data  has  been  described  in  Section  VII. 
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Table  38  provides  the  task  IDs  that 
were  allocated  to  the  various  application 
programs  that  were  used  in  this  case  study, 
the  memory  resource  requirements  as 
obtained  from  the  simulation,  and  the 
execution  time  for  each  task,  also  obtained 
from  the  simulation.  This  information  plus 
I/O  data  that  was  analyzed  from  the  output 
of  the  process  constructor  was  used  as  input 
data  parameters  to  the  task  definition  pro- 
cedure for  tiic  SMS  as  described  in  Section 
VII. 

Table  30  provides  IDs  of  subfunctions, 
their  iteration  period,  ‘.'..id  their  time  of 
initiation  relative  to  one  another.  These 
subfunctions  are  the  programs  which  must 
be  time-scheduled  by  the  GEX.  The  sub- 
function definitions  provide  a time-oniered- 
list  for  the  GEX  for  this  purpose.  Certain 
messages  that  are  transfenw  over  either  bus 
in  the  DP/M  system  do  not  have  successors. 
To  elaborate,  these  messages  do  not  cor'ain 
the  predecessor  count  of  their  destination 
task  They  are  required  by  the  task,  but  are 
nor  critical  in  terms  of  timely  arrival  for  the 
task  execu' ion.  Then,  me* sages  generally  are 
transmitted  at  rates  slower  than  the  iteration 
rate  of  their  destination  tasks.  In  the 
simulation,  these  messages  are  allocated  IDs 
from  300  up. 

7.  Simulation  Results 

The  reports  generated  o*  a simulation  run  for  the  case  study  are  summarized  in  the  reports 
found  in  Appendix  B. 

E.  RECOMMENDED  FUTURE  ACTIVITY  IN  DP/M  PROCESS  CONSTRUCTION 

t he  objective  of  this  subsection  is  to  make  several  recommendations  for  future  R&D  work 
ir.  DP-'M  process  construction.  These  recommendations  are  based  on  the  experience  accumulated 
during  the  course  of  work  described  in  this  report.  As  mentioned  in  the  discussion  of  ai.'omation 
of  process  construction  (Subsection  1X.B.3K  the  preparation  of  process  construction  inputs  and 
the  conversion  of  its  outputs  to  simulation  (or  to  process  linking/loading)  in;  uts  were  foreseen 
to  be  the  potentially  biggest  bottlenecks  in  the  entire  process  construction  procedure.  The 
ex, XT' mental  work  carried  out  within  the  framework  of  process  construction  study  has 
confirmed  this  suspicion.  The  means  for  eliminating  these  bottlenecks  are  within  the  present 
state  of  the  art  and  are  economically  feasible.  Hence,  it  is  recommended  that  the  early  and  late 


b RADARSS 

7 RADAL.TSS.  GYRALSS, 

DOPPLER 

K ECMSS.  COMMSS 

9 STOMANSS,  ENDSTO 

10  STOMANSS 

1 1 INSNAV 

12  LORAN 

13  RHAW 

14  FL.1RPTG 

15  NARBSWD 


TABLE  36.  PROGRAM  ALLOCATION  SUMMARY 
PE 

Number  Program  Allocated 

1 GEX 

2 AIRDATA.  M1SSMGT,  NAVF1LT, 
A1RCRFSS 

3 CNPANM  AN . CNPANSS 

4 DISPLMAN 

5 FLTCONT 


TABLE  37.  GLOSSARY  OF  APPLICATION  PROGRAM  NAMES 


!, 

I 

$ 


► 


F 


l 


AIRDATA/AIRDATASS 

CNPANSS 

CNPANMAN 

DJSPLMAN 

DISPLSS 

FLTCONT/FLTCONSS 

MISSMGT 

NAVFILT 

RADARSS 

RADALTSS 

HCMSS 

COMMSS 

A5RCRFSS 

GYRACCSS 

STOMANSS 

INSNAV/INSSS 

DOPPLER/DOPPSS 

LORAN/LORANSS 

RHAWGTL 

FURPTG/FLIRSS 

NARBSWD 


AIRDATA.  AIRDATA  SUBSYSTEM  SERVIC  E 
CONTROL  PANEL  SUBSYSTEM  SERVICE 
CONTROL  PANEL  MANAGEMENT 
DISPLAY  MANAGEMENT 
DISPLAY  SUBSYSTEM  SERVICE 

FLIGHT  t ^ NT  ROLF  LIGHT  CONTROL  SUBSYSTEM  SERVICE 

MISSION  MANAGEMENT 

NAVIGATION  FILTER 

RADAR  SUBSYSTEM  SERVICE 

RADAR  ALTIMETER  SUBSYSTEM 

ECM  SUBSYSTEM  SERVICE 

COMMUNICATION  SUBSYSTEM  SERVIl  h 

AIRCRAFT  STATE  SUBSYSTEM  SERVICE 

GYROS/ACCELEROMETER  SUBSYSTEM  SE1  VICE 

STORES  MANAGEMENT  SUBSYSTEM  Sl.RViCI 

INERTIAL  NAVIGATION/INS  SUBSYSTEM  SEE'1' 

DOPPLER  DOPPLER  SUBSYST  F.M  SERVICE 
LORAN/LORAN  SUBSYSTEM  SERVICI 
RHAW  SERVICE 

FLIR  POINTING  FLIR  SUBSYSTEM  SERVIC t 
NARBS  WEAPON  DEI  (VERY 


I.  Process  Construction  Inputs 

The  manual  work  needed  to  analyze  the  model  data  and  subsequently  to  prepare  the  process 
construction  inputs  can  be  reduced  by 

Introducing  an  extended  language  processor  winch,  besides  being  a comp  to:  in  tin 
ordinary  sense,  would  have  the  capability  to  analyze  the  sours,  •'!-'i,r  ni  um. 
extract  the  needed  model  data,  and  produce  the  representations  o;  •’’!!'  data  in 
the  form  directly  usable  by  the  Process  Constructor. 

Mechanizing  the  handling  of  model  data  through  the  facilities  ot  j ,onpulo./rti 
data  management  system,  discussed  in  Subsections  IX  B and  IX  , 

Several  possible  ways  fos  representing  the  process  model  to  the  pros  -s  uiacnutm  arc 
discussed  in  Subsection  1X.B. I . What  has  been  proposed  lor  the  Basic  PhiU"  ( onor'ictoi 
constitutes  a relatively  simple  but  restricted  approach  Although  this  method  is  sulti  uai  tor  tlw 
procedure  specified  in  Subsection  IX.C  . it  is  recommended  that  alternative  and  possibly  mote 
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TABLH  38.  TASK  10.  MEMORY  AND  EXECUTION  TIME  SUMMARY 


Ta*  Name 

T mk  ID 

Memory  Required 

Execution  Time 
<P*> 

AIRDATA/AIRDATASS 

41 

1034 

4406 

CNPANSS 

43 

747 

11340 

CNPANMAN 

44 

561 

1387 

DISPLSS 

45 

324 

1630 

DISPLMAN 

46 

21  S3 

3670 

FLTCONT'FLTCONSS 

47 

2129 

5406 

MISSMGT 

49 

41 

TBD 

NAVFILT 

50 

PI  5 

228155 

RADARSS 

51 

i 240 

2739 

RADALTSS 

52 

301 

883 

ECMSS 

53 

480 

1682 

COMMSS 

54 

580 

5072 

AIRCRFSS 

55 

l°5 

2..2N 

GYRACCSS 

56 

114 

'38 

STOMANSS 

57.  58.  15' 

5928 

8002 

INSNAV/INSSS 

59 

2529 

91  :i 

DOPPLER/DOPPSS 

61 

71 5 

253! 

LORAN  LORANSS 

63 

2625 

13656 

RHAWGTL 

6' 

766 

23130 

FURTG  FURSS 

6 7 

2249 

~ 3~4 

NARBSWD 

6‘1 

3 U0 

1 7469 

general  and  powerful  method'  oe  investigated.  The  t«\u  objective  ot  these  invest igations  would 
he  to  come  up  wit'  -c  lei  repre'entJtion  forms  which 

O be  n.i  .naticallv  generated  as  a by-product  ot  compilation 

• . *.*<*  .e.it  the  piocess  control  dynamics  and  data  How  by  a single  directed 

graph 

Would  be  relatively  independent  from  the  design  alternatives  tor  the  system  under 
development 
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TABLE  19.  SUBFUNCT10N  INFORMATION  SUMMARY 


Subtraction 

ID 

AIRDATA/AIRDATASS 

I 

CNP/NSS 

2 

DISPLSS 

3 

FLTCONT/FLTCONSS 

5 

M1SSMGT 

6 

NAVFILT 

7 

RADARSS 

8 

RADALTSS 

9 

ECMSS 

10 

COMMSS 

1! 

AIRCRFSS 

12 

GYRACCSS 

13 

STOMANSS 

14 

1NSNAV/INSSS 

15 

DOPPLER/DOPPSS 

16 

LORAN'LORANSS 

17 

RHAWGTL 

18 

FLIRPTG/FLIRSS 

19 

NARBSWD 

20 

Iteration  Period 

Time  of  First 
“GO"  Mcmfe 

62.500 

3.000 

62,500 

1,000 

250,000 

2.000 

15.625 

4.000 

1.000.000 

9.000 

8.000.000 

125,000 

31.250 

5,000 

31.250 

6,000 

31.250 

8.000 

62,500 

15,000 

125,000 

7,000 

31.250 

37.000 

62.500 

0 

31.250 

10.000 

31.250 

1 1 2200 

3 1 2150 

43.650 

31.250 

11.600 

31.250 

19.000 

31.250 

A survey  of  current  literature  1 references  ( 1 2 ).  (14i  and  (15)  are  recommeni  ed  as  a point 
of  departure  for  further  research!  suggests  that  Petn  nets  and  related  graphs  may  otter  a medium 
for  a combined  representation  of  process  control  and  data  How  implied  in  the  second 
requirement  above.  Especially,  the  so-called  Macro  h-Nets  ! reference  (1 5 ))  appear  to  be  capable  of 
combining  the  control  and  data  flow  information  under  the  same  graph.  Macro  E-Nets  are 
suitable  for  representing  a wide  class  of  parallel  compu'ational  processes.  Hence,  they,  in 
principle,  meet  the  third  requirement 


14 Miller.  R.E.:  "A  Comparison  of  Some  Theoretical  Models  of  Parallel  ComputaUon."  It'Ht  Trarnai lions  on 
CumfHiten.  Vd.  C-22,  «8  (August  1 >73). 

15  Noe,  J.D..  and  GJ.  Nutt:  “Macro  E-Neis  for  Representation  of  Parallel  Systems."  IHFH  Transactions  on 
Computer s.  Vol.  C-22.  aft  (August  1973). 
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Next,  the  question  arses  whether  such  graphs  can  be  generated  as  a by-product  of 
compilation.  To  our  best  knowledge,  this  still  is  an  open  problem,  which  should  be  further 
investigated.  Two  remarks  are  pertinent  at  this  point: 

Automatic  generation  of  such  graphs  is  not  only  a property  of  these  graphs  but  also 
a characteristic  of  the  language  processors  under  consideration 

Certain  types  of  information.  »uch  as  program  scheduling  rates,  normally  are  not 
available  at  compilation  time  and  hence  must  be  independently  provided  by 
the  process  designer. 

Thus,  even  in  a highly  automated  process  construction  environment  (as  shown  in  Figure  178) 
there  will  be  two  input  streams:  one  produced  by  the  language  processor:  another,  by  the  process 
designer. 

2.  Process  Construction  Outputs 

Similarly,  it  is  recommended  that  the  final  phases  of  process  construction  be  more 
extensively  mechanised  and  simplified  than  is  stated  in  the  design  requirements  for  the  Basic 
Process  Constructor  (Subsection  IX.C).  This  can  be  done  by  defining  a standard  way  to  represent 
the  models  of  a wide  class  of  real-time  processes  for  multiple  computer  networks.  The  present 
design  of  the  DP'M  hardware  software  would  constitute  a particular  case  of  such  a generalized 
model  class. 

The  advantages  of  such  an  approach  are 

Creation  of  a standard  interface  between  the  process  constructor  and  the  users  of 
process  construction  outputs  (vanous  simulators,  program  linker-loaders) 

Easier  automation  of  the  final  steps  of  process  construction. 

A standard  interface  would  serve  a twofold  function  first,  it  would  make  process  construction 
relatively  independent  from  the  particular  design  of  the  Executive  or  from  the  software 
architecture  of  the  system  under  development,  secondly,  process  construction  outputs  would 
become  available  to  the  user  programs  in  a more  readily  accessible  form,  which  would  also 
reduce  the  cost  and  time  required  to  develop  stub  post-procesx-construstion  support  programs. 

The  nght-hand  side  of  Figure  178  shows  the  toregoing  ideas  on  standardized  outputs  by 
showing  a process  constructor  communicating  with  several  post-process-construction  user 
programs  through  a common  Process  Construction  Output  File.  Typically,  a consumer  ol  the 
process  construction  outputs  uses  only  a portion  of  the  available  data.  For  example,  the  memory 
maps  used  by  the  process  loader  are  of  no  or  little  interest  in  simulation,  on  the  other  hand, 
much  of  the  program  execution  timing  data,  which  is  of  great  interest  in  simulation,  is  not  used 
in  the  execution  of  the  process  software  on  the  target  computer  system.  Hence,  every  user 
program  must  be  provided  with  an  input  routine  whose  function  would  be  to  ret  neve  and 
reorganize  appropnate  portions  of  the  Process  Construction  Output  File. 

Defining  such  a generalized,  standard  process  construction  output  model  for  DP  M is  a 
simple  task.  What  is  important  is  that  it  be  defined  before  the  design  of  process  constructor  and 
of  other  support  software  has  progressed  too  far.  In  this  respect,  the  situation  is  analogous  to  the 
development  of  system  software:  the  composition  and  formats  of  object  programs  must  be 
defined  before  the  design  of  language  processors  and  link-loaders  can  be  completed. 
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Figure  ! 78.  Automation  of  the  Initial  and  Final  Stages  of  Process  Configuration 


SECTION  X 

FAULT-TOLERANCE  ANALYSIS 


A.  INTRODUCTION 

The  goal  of  the  fault-tolerance  analysis  task  was  to  identify  potential  methods  of 
exploiting  the  DP/M  system  architecture  to  provide  overall  avionic  system  fault-tolerant 
capabilities  during  the  performance  of  an  aircraft  mission.  It  was  recognized  that  the  DP/M 
system  philosophy  is  potentially  amenable  to  techniques  of  graceful  degradation  to  achieve 
functional  fail-soft  levels  of  fault  tolerance,  due  to  the  absence  of  a complex  central  processing 
resource  within  the  distributed-function  system  environment.  Additionally,  the  low  increment-of- 
capability  concept  used  in  DP/M  system  construction,  with  the  use  of  low  complexity  and  cost 
homogeneous  microprocessor  hardware,  permits  practical  adoption  of  conventional  hardware 
redundancy  techniques.  Thus,  both  functional  and  physical  redundancies  were  identified  as  the 
two  basic  methods  by  which  the  DP/M  design  could  facilitate  overall  system  fault  tolerance. 
Accordingly,  the  unique  requirements  of  each  method,  with  respect  to  the  DP/M  application, 
were  Investigated  during  system  design.  Each  phase  of  functional  element  design  was  cognizant  of 
this  overall  goal  in  an  attempt  to  provide  an  accommodation  of  satisfactory  fruit- tolerance 
car-abilities  at  each  system  component  level. 

A primary  objective  o:  the  fault-tolerance-analysis  activity  was  to  initially  identify  and 
examine  the  various  failure  modes  possible  within  the  overall  avionics  system.  More  specifically, 
those  failures  which  can  be  attributed  to  DP/M  system  components  were  identified  and 
investigated  in  an  effort  to  prevent  the  DP/M  system  itself  from  introducing  any  detrimental 
effects  on  overall  system  reliability,  especially  with  respect  to  flight-critical  system  functions.  As 
a complementary  effort  to  the  above  objective  of  analyzing  system  failure  modes  and 
mechanisms,  the  fault-tolerance  analysis  also  dealt  with  the  task  of  identifying  fault  recovery 
techniques  which  could  be  effectively  used  to  satisfy  these  requirements. 

In  summary,  it  was  the  intent  cf  the  DP/M  fault  tolerance  analysis  to  identify,  examine, 
and  determine  the  potentially  advantageous  and  disadvantageous  characteristics  inherent  in  the 
DP/M  system  architecture  with  respect  to  overall  aircraft  fault  tolerance  and  reliability. 
Exploitation  of  the  advantageous  attributes  and  elimination  of  the  detrimental  attributes  were 
underlying  motives  within  this  design  intent.  This  analysis,  accordingly,  does  not  propose  to 
develop  an  ultimate  fault-tolerant  system  design  which  advances  the  state-of-the-art  of  fault- 
tolerant  compuung  systems.  Only  the  determination  of  those  techniques  which  can  be  applied  to 
enhance  or  use  the  inherent  fault-tolerant  capabilities  existent  in  a generic  DP/M  system 
comprising  a network  of  homogeneous  PEs  is  sought. 

B.  FAULT-TOLERANCE  APPROACH 

System  reliability  and  fault  tolerance  are  inherently  interrelated  attributes  of  a given 
system  design,  however,  some  confusion  may  exist  concerning  the  effects  of  one  attribute  on  the 
other.  With  respect  to  avionic  system  configuration,  the  term  “reliability"  is  often  used  in 
different  contexts.  Simply  stated,  “reliable”  has  different  meanings  to  different  system  users.  At 
the  user  (pilot)  level,  reliability  is  used  in  conjunction  with  the  probability  of  mission  success.  At 
the  system  component  (maintenance  officer)  level,  reliability  is  measured  with  respect  to 
individual  system  component  farina*  probability.  Before  the  use  of  integrated  avionic  system 
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techniques  the  two  interpretations  of  "reliable”  were  exactly  equivalent,  i.e..  individual  hardware 
component  failures  were  directly  reflected  at  the  system  user  level  by  the  attendant  loss  of  some 
functional  capability  associated  with  the  tailed  component.  Integrated  systems  such  as  DP/M. 
however,  can  make  a component  failure  transparent  at  the  system  user  level  via  the  use  of 
redundant  resources  for  automatic  failure  back-up  and  recovery.  Hence,  the  term  fault  tolerance 
directly  implies  system  resource  redundancy  when  used  in  conjunction  with  DP/M-like  systems. 
Fault  tolerance  does  not  entirely  eliminate  the  need  for  reliable  components:  instead,  it  offers 
the  option  to  allocate  part  of  the  reliability  resources  to  the  use  of  redundancy.  Resource 
redundancy  can  generally  be  provided  by  two  basic  techniques'  functional  and  physical 
redundancy  implementations. 

1.  Functional  Redundancy 

Functional  system-level  redundancy  within  an  avionics  system  is  popular  in  press  .t 
integrated  avionics  systems,  as  evidenced  in  the  A-^D.  F-ill.  F-15.  and  the  proposed  DAIS  hot 
bench  avionics  systems.  The  integration  of  the  various  sensors,  displays,  and  unique  avionics 
devices  offers  the  system  architect  multiple  methods  of  performing  diflerent  functions.  Ak 
failures  m a given  subsystem  are  recognized,  one  of  three  alternative  strategies  may  be  used  to 
"mask”  the  failure  (completely  or  partially) 

Derive  faikd  function  equipment  outputs  required  by  other  related  system  functions 
trom  an  alternate  source,  thus  prohibiting  failure  propagation  to  other 
dependent  functions 

Invoke  an  alternate  mode  of  failed  function  performance  at  the  probable  expense  of 
system  performance  (i.e..  degraded  mode) 

Reallocate  available  system  resources  to  the  performance  of  all.  or  the  highest, 
priority  functions. 

All  failure  recovery  alternatives  above  indicate  the  implied  association  of  potential  overall 
system  degraded-mode  operation  associated  with  tunctional  redundancy  techniques.  These 
techniques  fall  under  the  category  of  “graceful  degradation.”  Basic  to  the  concept  of  graceful 
degradation  is  the  idea  that  any  paiticular  system  element  normally  performs  certain  fixed  tasks., 
but  can  also  assume  additional,  or  different,  tasks  ( inclusively  or  exclusively)  when  another 
element  fails.  An  example  of  a simplified  graceful  degradation  procedure  anp'- cable  to  an  aircraft 
navigation  subsystem  is  shown  m Figure  1 In  this  example,  the  loss  of  j primary  navigation 
subfunction  due  to  associated  sensor  or  PI  failure  causes  the  overall  navigation  processing  to 
revert  to  an  alternate,  degraded  mode  ol  operation.  All  recovery  actions  involve  only  software 
mode  switching  in  tne  operational  Pf-.s.  Graceful  degradation  techniques  attempt  to  mask  system 
faults  as  much  as  possible,  though  not  necessarily  completely,  trom  the  svstem  manager  t pilot i 
In  general,  graceful  degradation  techniques  otter  the  least  costly  approach  to  fault-tolerance 
capabilities.  Addition  ol  these  techniques  in  system  design  imposes  the  requirements  1 1 1 that 
lailures  be  uetected.  (2)  that  necessary  memory  and  processing  capabilities  he  available  lor 
back-up  programs,  and  1 3 » that  the  reconfiguration  sot t ware  be  developed,  no  hardware  additions 
are  required. 

Another  generic  attempt  at  offering  system-level  functional  fault  tolerance  is  known  as 
"dynamic  resource  allocation.”  fins  technique  provides  tor  switching  of  system  elements,  ot 
resources,  trom  task  to  task,  to  match  dunging  work  Uud  and  the  availability  ol  operational 
elements.  Ih’is,  "dynamic  redundancy"  is  available  lot  most  piocVssmg  tunctions.  However,  the 
hardware,  and  especially  software,  requirements  <>l  this  approach  are  nv.idi  more  complex  than 


those  associated  with  graceful  degradation  techniques,  because  the  scheduling  programs  must 
continuously  solve  the  problems  of  task  and  resource  compatibility.  Additionally,  the  resource 
allocation  control  processing  degrades  overall  system  performance  capabilities  available  to 
applications  task  processing.  These  disadvantages  forced  the  elimination  of  dynamic  resource 
allocation  system  operation  early  in  the  system  design 

2.  Physical  Redundancy 

Phyticj.  redundancy  techniques  use  replication  ot  system  hardware  elements  to  achieve 
system  fault  tolerance.  Redundant  physical  elements  can  he  used  as  "dedicated"  or  "dynamic" 
functional  b?ck-up  units.  The  use  ot  dedicated  function,  or  “simple"  redundancy  techniques  is 
an  obvious  method  of  increasing  mission  success,  but  at  the  probable  expense  of  increased  failure 
rate  and  system  costs.  caused  by  added  hardware  complexity.  Physical  redundancy  also  requires 
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in-flight  monitoring  to  determine  which  redundant  element  is  operating  incorrectly  and  to 
guarantee  use  of  the  healthy  element  only.  Functionally,  this  monitoring  can  be  achieved  by 
either  software-  or  hardware-implemented  techniques. 

Physical  redundancy  with  hardware  monitoring  and  redundancy  management  is  readily 
justifiable  for  flight-critical  functions  because  of  safety-of-flight  considerations.  Such  techniques 
are  presently  used  in  Fly-by-Wire  (FBW)  flight-control  systems  where  process  control  elements 
are  used  with  hardware  “voting”  mechanisms  to  achieve  an  ultra-high  degree  of  fault  tolerance. 
However,  for  functions  which  are  non-flight-criticai,  the  idea  and  application  of  hardware 
redundancy  must  be  viewed  carefully.  Practically,  the  use  of  redundant  hardware  resources  that 
have  comparatively  low  system  MTBFs  may  not  be  justified  in  terms  of  mission  safety  and 
system  cost  effectiveness.  A component  that  is  relatively  low  in  terms  of  its  system  reliability 
usually  has  a number  of  parts  that  contribute  to  this  unreliable  nature.  Consequently,  the  system 
can  have  a tendency  to  be  self  defeating:  in  an  attempt  to  increase  reliability  via  redundant 
hardware  resources,  the  system  may  actually  be  less  reliable.. 

Another  point  to  consider  with  respect  to  simple  physical  redundancy  involves  the 
determining  of  which  components  of  a function  must  be  redundant.  If  one  component  has  an 
MTBF  that  is  several  orders  of  magnitude  higher  than  that  of  another  component,  it  does  not 
increase  the  overall  system  reliability  to  add  hardware  redundancy  to  the  most  reliable 
component  without  added  redundancy  to  the  less  reliable  component.  Such  is  the  case  with 
airborne  digital  processors  and  most  avionic  sensor/ actuator  equipments,  the  mean-time-bet  ween- 
failures  (MTBFs)  of  “sensors”  range  typically  between  100  to  2.000  hours,  whereas  airborne 
digital  processor  MTBFs  range  from  1,000  to  30,000  hours  for  contemporary  hardware  with 
10,000  to  100,000  hours  anticipated  for  DP/M-like  LSI  PEs.  Consequently,  if  the  goal  is  to 
increase  system  or  function  reliability,  it  may  be  necessary  to  add  redundancy  to  only  part  of 
the  system. 

C.  APPROACH  TO  FAULT  SPOTTING 

During  the  investigation  of  functional  and  physical  redundancy  techniques,  it  was  apparent 
the  key  factor  affecting  the  effectiveness  of  both  redundancy  techniques  is  fault  spotting,  or 
fault  detect«on.  In  a system  using  non-self-repainng  hardware  components,  faults  must  be 
detected  and  recognized  by  the  system  fault  recovery  “intelligence”  (software)  before  recovery 
procedures  can  be  invoked.  Simple  physical  redundancy  approaches  are  dependent  upon  the 
correct  monitoring  and  detection  of  system  faults  when  they  occur,  and  proper  determination  or 
isolation  of  the  faulty  system  element  to  allow  selection  of  the  correct,  operational  redundant 
unit. 


Generally,  system  tailures  manifest  themselves  in  one  of  two  basic  categones.  “hard"  or 
“soft.”  “Hard”  failures  include  permanent  equipment  failures  and  are  typified  by  physical 
hardware  damage  or  delect.  “Soft"  failures  is  a term  used  to  categon/c  transient  or  intermittent 
failures  at  any  level  of  system  operation.  Representative  of  this  class  of  failures  are  temporary 
data  errors  (e.g..  bit  error)  caused  by  either  the  system  environment  l noise)  or  hardware  faults 
caused  by  marginal  component  operation  or  design  Haws.  Software  error*  are  ubo  included  tn 
this  category  of  failures. 

“Hard”  and  “soft”  failures  must  be  discriminated  by  both  the  fault  detection  and  failure 
recovery  system  processes  to  achieve  true  overall  system  fault  tolerance.;  “Soft"  failures  are 
usually  detected  by  data  validity  checks  (hardware  or  software  implemented)  at  various  points  in 
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the  system.  The  system-level  criticality  and/or  error  susceptibility  ot  the  data  being  checked 
usually  dictates  the  method  of  validity-checking  used.  Data  validity  checking  techniques  can 
range  from  software  "reasonableness  checks”  to  hardware  use  ot  self-correcting  data  codes.  The 
detection  of  soft  failures  is  necessary  at  the  individual  PE  level  to  allow  the  various  associated 
system  software  elements  to  locally  “block"  or  “mask”  erroneous  data  at  the  earliest  possible 
level  to  prevent  its  potential  propagation  throughout  the  system.  Detection  of  “hard”  failures  is 
necessary  to  allow  defective  component  isolation  so  that  proper  redundancy  management  control 
(functional  or  physical)  can  be  performed. 

As  a basic  design  precept,  it  was  decided  to  ensure  the  fault-tolerant  integrity  of  the  DP/M 
system  elements  themselves,  as  a first  step  toward  achieving  overall  avionic  system  fault-tolerance 
capability.  Thus,  the  various  potential  failure  sources  within  the  DP/M  elements  were  identified 
and,  accordingly,  the  necessary  detection  mechanisms  required  for  each  fault  were  considered  in 
the  individual  component  designs.  The  resultant  DP/M  hardware  design  provides  failure  detection 
in  every  area  of  component/system  operation  that  could  be  destructive  to  individual  functions  or 
system  level  operational  integrity.  All  hardware-detected  faults  cause  an  associated  interrupt  to 
directly  alert  the  PE  software  program  oi  the  fault  condition.  The  purpose  and  operation  of 
these  fault-detection  mechanisms  have  been  delineated  in  previous  hardware-design  sections  and 
need  not  be  reiterated  here.  Instead,  a summary  of  potential  failures  typical  to  the  DP/M  system 
and  their  associated  detection  mechanisms  is  presented  in  Table  40. 

From  an  overall  system  viewpoint,  the  DP/M  design  supports  continuous  built-in-test  (BIT) 
techniques  of  system  operational  integrity  testing  in  both  background  and  foreground  processing 
modes.  For  example,  each  PE  is  provided  with  hardware  mechanisms  to  support  interruptible 
background  Performance  Assurance  Test  Software  (PATS)  dunng  PF  “idle”  time,  when  no 
avionics  processing  is  being  performed.  Also,  special  Bus  interface  Unit  hardware  design  supports 
simultaneous  message  transmission  and  reception  capability  (i.e..  input/output  rebound)  to  allow 
a software-controlled  self-test  of  the  BIU  component  normal  operating  characteristics. 

Built-In-Test  methods  of  fault  detection  and  isolation  may  be  extended  beyond  the 
individual  PE  level  to  the  overall  system  level  via  the  DP/M  communications  facilities.  Global 
Executive  (GEX)  scheduling  procedures  accommodate  the  periodic  scheduling  of  system-level 
PATS  upon  request  and  control  of  the  ensuing  "health-status"  communications  with  each  PE. 
Additionally,  the  BIU  interrupt  mechanisms  allow  immediate  GE.X  response  to  locally  detected 
errors/faults  reported  by  individual  PF.s  via  the  busing  facilities.  These  locally  detected 
errors/faults  may  be  either  PE  failures  or  external  I O device  tailuivs.  External  am.  rail  device 
failures  are  detected  via  both  the  10  interface  hardware  and  software  checks  performed  on  I/O 
data  (e.g..  reasonableness).  If  individual  l 0 device  characteristics  permit.  BIT  communications 
with  the  I/O  devices  (i.e..  with  I/O  device  BIT)  can  be  invoked  by  the  system  PEs.  with  device 
status  interrogated  at  the  local  level  and  reported  to  the  system  error  monitor  (GEX)  if  failures 
are  detected. 

The  preceding  approach  to  detecting  individual  avionics  equipment  faults  with  the  PE  to 
which  it  interfaces  may  be  advantageous  with  respect  to  overall  system  operational  integrity.  Due 
to  the  inherent  preprocessing  or  “smart  terminal"  characteristics  afforded  by  the  DP/M  system 
architecture.  I/O  device  faults  can  be  readily  detected  by  the  device-interfacing  PF  and  thus 
prevented  from  possibly  propagating  throughout  the  total  system:  transient  data  errors  can 
perhaps  even  be  corrected  (e.g..  via  re-issuance  of  the  data  transfer,  use  of  sot t ware-handled 
error-correcting  codes,  etc.)  by  the  PE  before  distribution  to  the  remainder  of  the  system,  thus 
offering  potential  system  tault  tolerance  to  intermittent  device  cnors' faults. 


TABLE  40  POSSIBLE  DP/M  SYSTEM  FAILURES  AND  ASSOCIATED  FAULT  DETECTION 


Failure  Source /Type 
PE 

Memory  Control 

Memory  Data 

Illegal  Memory  Reference 

Instruction  Failure 
Illegal  Op-code 
Arithmetic  Overflow 
Hang-up  (Hardware  or  Software) 

Incorrect  Inter-PE  Data 

Bus  Control  Interface  Operation 

Invalid  Position  j 

Bus  Quiescence  i 

“Chatty”  Terminal  j 

Excessive  Message  Length 

Bus  Data 

Environment-Induced  Noise 
Erroneous  Supercommutation 
Data  BIT  Error  (Random.  Burst) 

Added  Bit,  Dropped  Bit 
Message  Identity  Error 

10  Device 
Sensor 

Mass  Memory 


Detection  Mechanism /Technique 


Memory  Response  Check  (Timeout) 
Parity  Check 

Memory  Response  Check  (Address 
Out-of-Range)  and  Write  Protect 
(Optional) 

Software  BIT 

Firmware  Detection 

Hardware  Detection 

Missed  Real-Time  Schedule 
(Software  Detected) 

BtU  (Software  Detected)  Data 
Validity  Check  Hardware 


BIU  W-tch  Dog  Timers 

(Global  BIG  Hardware  Check 
( Local  Software  Prow 


Bi-Phase  Encoding  and  Data  Pants 
Checks 

Message  Bit  Length  Check 

Bi-Phase  Encoding 
. Parity/Missed  Message  (Software 
( Detected) 


Device  Response  Check.  Reason- 
ab!encs»  Test  (Software).  Device 
BITF  Interrogation 

Validity  Code  Checks 


D.  FAILURE  RECOVERY  APPROACH 

The  DP/M  system  design  appears  equally  amenable  to  the  use  of  functional  or  physical 
redundancy  techniques  from  the  viewpoint  that  neither  the  system  nor  component  designs 
contain  any  inherent  attributes  which  functionally  or  physically  preclude  the  use  of  either 
technique.  The  determination  of  which  technique  is  more  desirable  is.  however,  dependent  upon 
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the  peculiar  recovery  requirements  o!  each  avionic  function  performed  by  the  DP  M system 
during  a particular  aircraft  mission,  and  thus  a universal  solution  foi  every  application  i*  not 
realizable.  However,  certain  guidelines  or  concepts  can  be  identified. 

The  choice  of  recovery  technique  is  extremely  important  to  achieving  satisfactory  system 
tolerance  to  functional  failures.  The  type  of  recovery  technique  permissible  (desirable)  for  a 
given  functional  failure  is  directly  dependent  upon  the  redundancy  method  used  to  otter 
fault-tolerant  capabilities  to  the  performance  of  the  function.  The  type  of  redundancy  technique 
chosen  is  usually  a trade-off  decision  between  economics  3nd  function  critically,  i.e...  lail-sott 
operation  (graceful  degradation)  versus  fail-safe  operation  (absolute  physical  back-up,  seil- 
repairability ).  Once  this  decision  is  made,  the  primary  factor  in  determining  failure  recovery 
technique  in  a real-time  system  is  the  required  responsiveness  of  the  system.  This  determination 
may,  in  turn,  face  reevaluation  of  the  redundancy-type  decision.  To  determine  failure-recovery 
responsiveness  of  the  avionic  system  to  individual  failures,  the  unique  real-time  requirements  of 
each  processing  function  must  be  analyzed  to  determine  the  amount  of  recovery  time  allowed 
before  function  performance  is  degraded  to  an  intolerable  level. 

Generally,  fail-soft  recovery  techniques  are  satisfactorily  applicable  to  most  minion- 
dependent  functions:  expensive  fail-safe  techniques  are  usually  warranted  only  for  functions 
where  safety-of-flight  considerations  rul  out  any  compromise  in  absolute  favor  ol  economics. 
Contemporary  studies  of  avionics  system  designs  have  generally  concluded  that  the  only  truly 
flight-critical  function  requiring  ab-olute  fail-safe  operation  in  tactical  aircraft  applications  is 
associated  with  FBW  flight  control.  The  currently  recommended  fad-sale  approach  to  (light 
control  system  design  is  the  use  of  triple  or  even  quadruple  redundant  systems  with  t.uiure 
detection  and  recovery  accomplished  concurrently  with  "hardware  voting"  mechanisms  which 
allows  complete  masking  of  single  (or  double)  system  failures  with  no  observable  effect  on 
real-time  performance.  It  is  recommended  that  a DP/M  implementation  of  LBW  functions  follow 
this  same  approach,  as  exemplified  in  Figure  180.  The  DP-M  PF  design  is  amenable  to  this 
“hardw3re-voted”  redundant  system  architecture.  An  Affinity  Group  required  to  periorm  all 
FBW  processing  functions  would  then  be  replicated  the  necessary  number  of  tunes  to  achieve  the 
desirable  level  of  redundancy.  The  DP/M  communications  design  facilitates  this  particular 
application  since  individual  processing  system  isolation  (functionally  and  puysicaliv i is  achieved 
by  Local  bus  and  “dedicated”  I/O  device  communications  while  communications  which  are 
required  to  be  common  between  each  individual  system  (and  the  remaining  avionics  system)  are 
accomplished  via  the  Global  bus  lacility.  It  is  also  recommended  that  the  Pi  s assigned  to 
flight-control  junctions  contain  ROM  implemented  program  memories  to  ensure  op-.>r  d 
integrity  under  circumstances  of  extreme  power  supply  fluctuations  or  tjih.ie.  This  ROM 
implementation  is  not  considered  to  introduce  any  disadvantage  associated  w't’n  system  flexibility 
(as  is  the  case  with  the  conventional  avionics  suite)  since  flight-control  algorithms  *and.  hence 
software  programs)  are  fixed  for  a given  airframe  ind  are  not  It!  ely  to  change  alter  final 
development, performance  validation  over  the  life  of  the  aircraft. 

The  remaining  complement  ot  aircraft  mission-related  tunctio.is  appear  amenable  to 
fail-soft  recovery  techniques.  Fail-sol!  recovery  imnhes  that  the  responsiveness  ot  tile  system  to 
individual  errors  or  faults  may  cause  transient  or  temporary  degradation  in  system  performance 
caused  by  execution  of  the  recovery  process,  The  particular  failure  recovery  approach 
recommended  tor  these  functions  requires  ihe  existence  ot  a GIN  software  System  fault 
Monitor  to  initiate  and  control  all  system  recovery  actions.  Busk  to  this  approach  is  the 
detection  of  failures  at  both  the  local  PL.  and  GL.X  levels.  Locally  detected  emirs  must  bc 
conveyed  to  the  G1  \ via  the  Global  bus.  11k  Gl  \ then  analv/es  the  tuilure  report  ami  initiates 


proper,  predetermined  recovery  activity,  if  required.  Normal  GEX  recovery  actions  would  be  to 
reduce  real-time  performance  (e.g.,  the  iteration  rate)  of  some  ptocessing  functions  and  possibly 
eliminate  other  functions  altogether  in  graceful  degradation  recovery  circumstances;  or  the  GEX 
may  deactivate  a faulty  system  device  and  activate  its  physically  redundant  counterpart  in 
managing  simple  physical  redundancy. 

Redundancy  control  can  be  implemented  at  the  local  level  for  external  device  failures 
where  necessary  equipment  redundancy  exists.  Knowledge  of  total  system  status,  however,  is  still 
maintained  by  the  GEX  via  failure  reports  or  active  failure  detection  by  the  GEX  itself  for 
future  recovery  or  post-flight  analysis  purposes.  In  its  fault-tolerance  role,  the  GEX  is  thus 
intended,  primarily,  as  a system  health-status  monitor  and  system-recovery  controller  for  DP/M 
system  component  failures.  Component  failures  dealt  with  by  the  GEX  are  generally  PE  failures 
or  busing  facility  failures. 

It  has  been  recognized  that  since  the  Global  bus  facility  is  the  only  “central”  resource  in 
the  DP/M  system  and  since  its  operational  integrity  is  imperative  lor  system  fault-recover; 
activities,  it  should  be  fault-tolerant  within  itself  to  the  fullest  degree  practicable.  This  resulted  in 
the  dual-redundant  Global  bus  approach  and  functional  design  discussed  in  Section  ME,  The 
system-level  management  and  control  of  these  redundant  global  buses  is  programmable  via  the 
GEX.  A comprehensive  complement  of  bus-fault  detection  mechanisms  are  provided  in  the  BIU 
hardware  to  allow  individual  PE  determination  of  bus-related  failures.  It  is  intended  by  design 
that  bus-data  errors  be  detected  at  the  individual  data  recipients  (PEs)  with  any  error  detection 
in  a message  transmission  reported  to  the  GEX.  The  GEX  can  then  request  message 
retransmission  or  take  other  action  as  appropriate.  For  major  busing-facility -related  faults  which 
impair  the  operation  of  the  entire  facility  (e.g..  bus  juiescence  or  dominance  conditions),  the 
Cil  \ assumes  both  detection  and  recovery  responsibilities.  Detection  is  performed  by  special  BIU 
hardware  with  the  additional  recovery  aid  of  automatic  halting  (disabling)  of  the  faulty  busing 
facility  oj>eration  so  as  to  allow  subsequent  GEX-driven  system  recovery  from  a known, 
controllable  state.  This  automatic  bus  “shut-down”  is  also  favorable  in  the  event  of  bus 
dominance  (“chatty”  terminal)  failures  since  it  offers  a first-level  attempt  at  ceasing  bus- 
dommating  activity  in  a faulty  PI . 

The  bus  failure  recovery  process  primarily  involves  establishing  individual  PE  (i.e..  BIU) 
operational  integrity  via  the  alternate  Global  bus  path  until  the  faulty  (fault-causing)  PE  is 
found.  This  procedure  is  effected  by  GEX  control  (via  bus  communication)  of  the  BIU  hardware 
elements  provided  in  each  PE  to  allow  switching  between  the  alternate  Global  bus  path 
connections.  For  bus  quiescence  errors,  this  process  may  be  eliminated  or  expedited  since  the 
"position”  ('f  the  bus-controlling  PF  (i.e..  the  probable  PF  in  error)  may  be  readily  extracted 
from  “global  bus  state”  information  resident  in  the  GEX's  own  BIU  Global  Bus  Position  Register 
(GBPR).  Dominance  errors,  however,  will  typically  require  a “chit-chat”  communication 
procedure  with  individual  PE'  to  isolate  the  faulty  PF.  Once  the  faulty  PE  is  determined,  it  may 
be  functionally  removed  from  the  system  by  methods  of  disabling  the  PEs  operation  in  the 
system  (i.e..  commanded  to  “shutdown”),  or  if  this  method  is  unsuccessful  because  of 
noiiresponsivencss  in  the  tailed  P*  . the  faulty  PE  may  be  "exiled"  from  the  system  by  removing 
it  (or  the  remainder  of  the  system  PEs)  to  the  unused,  redundant  global  bus. 

After  fault  Pr  removal  has  been  effected,  either  functional  or  physical  redundancy  control 
(depending  on  unique  system  doMgn)  is  accomplished  via  Global  bus  communication  from  the 
GEX  to  the  affected  PEs.  Finally,  the  system  state  and  bus  configuration  must  be  modified  and 
reinitialized  to  define  the  "new"  global  bus  configuration  before  system  restart  (bus 
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synchronisation)  and  recovery  completion.  Thus,  much  of  the  system  failure  recovery  activity  is 
similar  to  an  abbreviated  system  initialization  procedure. 

The  above  recovery  approach  requires  a variable  and  potentially  significant  amount  of 
response  time  in  execution.  The  actual  response  time  incurred  is  a function  of  the  type  of  tailure 
and  the  size  of  the  overall  system;  however,  preliminary  analysis  and  system  simulation  have 
shown  that  expected  response  times  are  relatively  short  (a  few  milliseconds)  with  respect  to  the 
execution  period  ot  most  real-time  avionics  processing  tasks  (10  milliseconds  to  1 second).  Thus, 
performance  degradation  incurred  because  of  failure  recovery  latency  is  expected  to  be  extremely 
transient  in  duration,  affecting  perhaps  a single  iteration  cycle  in  a real-time  avionics  process. 
Such  errors  tend  to  be  "filiered-out"  in  a few  subsequent  processing  cycles  in  most  proce^ 
investigated,  assuming  restart  trom  a known  state  is  properly  handled.  1 ius  requirement  to  m 
a known  state  is  one  justification  for  the  Gl.X  tightly  coupled  scheduling  of  subfunctions  on  a 
set  of  predecessor  conditions  that  include  “time  to  schedule."  This  “time  to  schedule"  can  also 
serve  as  a definite  checkpoint  of  current  system  status  and  a possible  departure  point  lor 
initiation  of  system-recovery  procedures.  Additionally,  the  lailtire-iccovery  process  may  have 
invoked  a degraded  mode  of  operation  tor  performing  the  failed  function  and/or  other  system 
functions,  thus  resulting  in  some  system  degradation  anyhow.  It  is  not  normally  believed  that  the 
relatively  slow  responsiveness  of  the  system  software  recovery  approach  will  significantly  affect 
most  mission-dependent  functions.  Those  functions  which  cannot  tolerate  the  processing  latency 
incurred  by  the  approach  should  be  provided  with  hardware  redundancy  control  and  recovery 
mechanisms  (e.g.  flight  control). 

In  summary,  the  DP/M  design  supports  either  or  both  physical  and  functional  fault 
recovery  techniques  without  basic  system  design  modification  Also,  “design-to-cost ” and  “pay- 
as-you-go”  design  philosophies  are  accommodated  by  supplying  a minimal  amount  ot  fault- 
tolerance  aiding  mechanisms  in  the  basic  system  component  design.  This  approach  allows  the 
construction  of  various  degrees  of  fault-tolerant  systems  at  the  option  of  individual  system 
designs,  paid  for  only  by  those  systems  which  require  the  increased  complexity. 

E.  POWER  SUPPLY  CONSIDERATIONS 

The  DP/M  processing  system  must  derive  its  power  from  the  types  of  primary  power 
generated  on  boa' d the  aircraft.  Primary  aircraft  electric  power  generally  is  available  as  1 20' 208 V. 
400  Hz.  three-phase  alternating  current  and  2X  VIX  . Primary  power  is  usually  "-nerated  by  one 
source  witi.  at  least  one  backup  source.  Tor  exan  Me.  the  A-"7  derives  its  power  from  a master 
AC  generator,  a battery  and  a ram-air-turbine.  w.iile  the  F-4  has  two  AC  generators.  The 
characteristics  of  the  various  power  sources  available  onboard  the  aircraft  are  defined  and 
governed  by  MIL-STD-704A. 

Several  power  buses  are  implemented  onboard  the  aircraft  to  route  the  generated  power  to 
devices  situated  in  different  locations.  Tor  example,  there  are  primary  and  secondary  AC  and  D( 
buses,  battery  buses,  and  emergency  buses  distributed  throughout  the  aircraft.  A device  is 
connected  to  one  or  more  huses.  depending  on  the  criticality  ol  its  tuiution.  Such  devices  can 
obtain  their  power  from  multiple  backup  sources,  if  needed.  Note  that  the  assignment  of  power 
buses  to  individual  avionic  equipments  is  determined  by  the  criticality  requirements  ot  functions 
using  the  equipments.  These  requirements  are.  in  turn,  aircralt-  and  mission-dependent. 

The  DP/M  power  supply (s)  must  provide  satisfactorily  regulated  IX"  power,  in  accordance 
with  individual  PL.  input  power  requirements.  It  miret  also  he  tolerant  ot  the  power  transient 
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characteristics  deftnea  in  MIL-STD-704A.  Since  the  DP/M  system  Processing  Elements  can  be 
implemented  with  potentially  volatile  semiconductor  memory  devices,  system  fault  tolerance  to 
power-failure  conditions  dictates  effecting  nonvolatile  memory  operations  at  the  system  level. 
This  nonvolatility  characteristic  can  be  achieved  by  either  use  of  nonvolatile  mass  memory  for  a 
system  memory  reload  capability,  or  actually  achieving  nonvolatility  at  the  individual  memory 
level  by  providing  an  “ultra-reliable”  power  source  for  the  memory  elements.  The  latter  approach 
is  recommended  for  DP/M  as  discussed  below. 

The  "ultra-reliable"  power  supply  must  be  capable  of  supplying  continuous,  uninterrupted 
power  to  the  PE  within  PE  tolerance  limits.  Since  the  primary  power  source  may  experience 
intermittent  periods  of  complete  power  loss  (e.g..  during  generator  failure),  an  “ultra-reliable" 
power  source  must  possess  a capability  of  energy  storage  or  generation  to  provide  continuous 
power  output  during  these  relatively  short  periods  of  primary  power  loss.  This  required 
capability  implies  the  use  of  a backup  battery  in  the  PE  power  supply  unii(s).  Battery- 
supplemented  power  supplies  are  not  new  to  digital  processing  equipment  design,  as  evidenced  by 
the  current  trend  to  use  such  techniques  in  many  contemporary  commercial  minicomputer 
systems  using  semiconductor  read/write  memories.  The  use  of  batteries  in  such  systems  is  usually 
accompanied  by  necessary  sacrifices  in  system  size,  weight,  and  complexity  (cost).  These 
disadvantages  are  usually  of  little  or  no  consequence  in  the  commercial  systems  applications 
mentioned,  but  may  present  a situation  of  significant  concern  when  applied  to  the  tactical 
aircraft  environment.  However,  t .*  low-power  consumption  properties  of  an  LSI  all- 
semiconductor PE  facilitates  the  use  of  “ultra-reliable”  power  supply  techniques  and  greatly 
alleviates  the  above  concerns  associated  with  battery-supplemented  power  supplies  in  the  aircraft 
environment. 

An  investigation  of  the  aircraft  power  environment  specified  in  MIL-STD-704A  indicates 
that  the  energy-supplying  capabilities  of  the  backup  battery  device  must  be  sufficient  to  sustain 
PF-required  power  levels  during  periods  when  primary  aircraft  power-supply  voltage-,  are  either 
disrupted  completely  (i.e.,  complete  power  failure)  or  temporarily  exceed  normal  steady-state 
limits  (e.g.,  power  out-of-tolerance  transients).  The  primary  aircraft  power  transients  condition 
specified  in  MIL-STD-704A  for  DP/M  class  equipment  are  shown  in  Figures  181  and  182  for  AC 
and  DC  power  use,  respectively.  The  power  transient  characteristics  shown  indicate  a possible 
worst  case  abnormal  (out-of-tolerance)  voltage  condition  duration  of  approximately  7 seconds. 
Therefore,  the  PE  power  supply  battery  element  must,  as  a minimum,  be  capable  of  sustaining 
PE  power  input  during  this  “possible”  transient  time.  However,  further  consideration  of 
maximum  possible  abnormal  power  level  time  duration  requires  the  battery  backup  to  supply  PE 
power  for  an  approximate  30-second  period  in  extreme  “abnormal"  circumstances:  this  more 
extreme  requirement  is  caused  by  maximum  anticipated  time  delays  required  to  switch  from 
primary  power  to  backup  power  in  the  event  of  total  primary/secondary  power  generation  failure 
(e.g.,  time  to  physically  deploy  ram-air-turbine  backup  system)  and  also  to  switch  from  ground- 
power  to  aircraft  power  during  flight-line  power-un  initialization  and  checkout  activities,  without 
requiring  reinitialization  of  PE  memories. 

The  above  environmental  constraints  placed  on  the  “ultra-reliable"  power  supply  operation 
may  be  used  in  conjunction  with  anticipated  PH  power  requirements  to  arrive  at  a quantitative 
estimate  of  actual  battery  requirements  and.  hence,  the  resultant  impact  on  power  supply 
implementation  complexity/practicality.  Determination  of  PH  power  requirements  during  system 
(aircraft)  power  failure  conditions  indicates  that  as  a minimum  absolute  requirement,  backup 
power  is  necessary  only  to  permit  retention  of  memory  data.  The  remaining  functional  elements 
of  the  PH  do  not  necessarily  require  continued  power  supply  during  periods  of  aircraft  system 
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Figure  181.  Transient  Surge  AC  Voltage  Step  Function 


power  failure,  since,  from  each  individual  PE  viewpoint,  PE  functional  utility  is  eliminated  when 
associated  aircraft  equipment  is  inoperative. 

However,  system-level  considerations  may  indicate  the  desirability  to  retain  PF.  operability 
during  “system-down”  time.  One  such  consideration  is  the  minimization  of  system  recovery  time 
following  power  resumption.  A complete  system  initialization  in  response  to  each  system  power 
failure  (transient  or  permanent)  is  obviously  undesirable  because  of  the  requirement  for  an 
“onboard”  program-load  device  (nonvolatile  mast  memory)  and  relatively  long  system 
initialization  times  incurred.  This  complete  system  initialization  requirement  is  eliminated  by  the 
recommended  concept  of  “ultra-reliable”  PE  power  supplies  which  prevent  PE  program 
destruction  and  obviate  any  program  reload  requirement.  However,  partial  system  initialization 
would  still  be  requited  to  reinitialize  or  reestablish  volatile  system  control  parameters  (i.e., 
register  contents)  such  as  those  required  for  inter-PE  bus  configuration  control  and  processor 
unit  program  registers.  Further  system  level  considerations  reveal  tne  potential  impact  of  the  loss 
of  power  in  a single  PE  or  Affinity  Croup  in  the  operation  of  the  overall  system  communications 
facilities.  Since  each  PE  connected  to  an  information  transfer  bus  must  actively  participate  in  the 
distributed  bus  control  procedure,  the  failure  of  a “powered  down”  PE  to  participate  could 
suspend  remaining  system  operations  until  an  abbreviated  system-level  bus  “reconfiguration”  is 
performed  to  remove  the  inoperative  PE.  In  addition,  when  power  is  restored,  the  affected 
subsystem  must  be  “brought  back”  into  the  system  by  another  “bus  configuration"  system 
control  procedure,  again  temporarily  suspending  other  functionally  independent  processes. 

Depending  on  individual  function  criticalities  with  respect  to  tolerating  possible 
suspensions  in  operation  and  the  potential  or  expected  frequency  of  aircraft  power  transient 
faults,  the  bus  reconfiguration  activities  mentioned  above  may  be  undesirable..  In  an  esthetic 
sense,  at  least,  it  does  not  appear  desirable  to  allow  a failure  in  one  system  function  to  affect  the 
operation  of  unrelated  functions  elsewhere  in  the  system. 

A possible  solution  to  this  problem  is  the  mandatory  attachment  of  each  DP/M  power 
supply  unit  to  the  same  levels  of  aircraft  primary  power  buses.  This  would,  however,  dictate  that 
each  PE  be  supplied  power  from  the  source(s)  required  for  the  most  critical  PE  function:  the 
requirement  may  be  unreasonable  or  impossible  becau>e  of  the  usual  relatively  limited  power 
output  capability  of  the  tactical  aircraft  backup  and  emergency  power  sources.  An  additional 
disadvantage  is  the  constraint  it  places  on  the  topological  distribution  of  the  various  power  buses 
throughout  the  aircraft.  This  constiaining  characteristic  would  violate  the  DP/M  system  design 
goal  of  permitting  and  supporting  physical  distributiveness. 

An  alternate  solution  is  the  existence  of  an  “ultra-reliable"  power  supply  for  every  system 
PE  (regardless  of  functional  assignment  or  memory  implementation)  to  support  the  bus  control 
activity  during  power  transients.  This  would  eliminate  the  possible  situation  of  individual  PE  or 
Affinity  Group  transient  power  failures.  The  only  power  failures  affecting  a portion  of  the 
overall  system  would  be  permanent  failure  of  either  the  associate  DP/M  power  supply  or  the 
primary  aircraft  power  source  to  which  it  is  attached. 

Investigation  into  the  actual  implementation  of  this  solution  was  performed  with  the 
primary  goal  of  minimizing  the  battery  backup  power  supply  requirements.  No  justification  for 
retaining  Processor  Unit  and  Input/Output  Interface  Unit  operation  is  necessary..  The  only 
functions  remaining  fully  operational  are  those  associated  with  the  hus  control  activity  in  the 
PE’s  Bus  Interface  Unit.  The  memory,  of  course,  requires  enough  power  to  sustain  data  retention 
as  mentioned  previously.  In  particular,  the  operational  status  of  the  BIU  need  be  preserved  only 
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for  the  Global  bus  interface.  Local  bus  activity  is  associated  strictly  with  intra-functional  activity 
and  is  thus  not  a factor  in  the  system-level  problem  being  addressed. 

Thus,  during  power-fail  conditions,  only  the  PE  memory  unit  and  Gbbal-bus-control- 
related  portions  of  the  BIU  require  continuous  backup  power;  the  remainder  of  the  PE  hardware 
components  are  allowed  to  “power-down.”  During  the  absences  of  satisfactory  primary  power 
and  upon  return  of  satisfactory  power  levels,  the  system  Phs  are  forced  into  a CLEAR/RESET 
state  by  the  power-detection  logic  within  the  PE  power  supply  unit.  The  initialization  control 
section  of  each  PE  then  controls  immediate  PE  operation  following  the  removal  of  its  CLEAR/ 
RESET  signal  just  as  it  does  during  a complete  system  initialization  procedure  (initial  system 
tum-on).  The  initialization  control  (bootstrap)  program  is  capable  of  distinguishing  a system 
restart  condition  from  a system-initialization  condition  and  directs  PH  activity  accordingly  (i.e., 
all  system  program  load  operations  in  the  normal  system  initialization  procedure  are  bypassed  in 
the  power  resumption/restart  procedure. 

Estimates  of  the  energy  storage  required  to  power  the  PE  memory  over  the  30-second 
maximum  aircraft  power  failure  require  quantitative  knowledge  of  unique  device  power 
consumption  characteristics.  The  candidate  semiconductor  read/write  memory  technologies 
recommended  for  DP/M  application  are  all  inherently  low  power  in  normal  operation,  with 
extremely  low-power  dissipation  characteristics  attainable  by  “standby”  modes  of  operation. 
Worst  case  standby  mode  estimates  for  the  various  candidate  technologies  n veal  estimated  power 
consumption  levels  on  the  order  of  SO  microwatts  per  memory  bit.  For  an  8K  memory 
configuration,  approximately  0.46  watt  of  power  will  be  required  to  support  standby  operation. 
This  power  consumption  requirement  converts  to  a battery  supply  capability  requirement  of  0.32 
mA-hr,  an  extremely  minimal  requirement. 

A quantitative  estimate  of  BIU  “standby”  power  requirements  is  slightly  more  complex, 
since  actual  power  consumption  may  depend  upon  the  physical  partitioning  of  the  BIU. 
Consequently,  it  appears  desirable,  for  the  sake  of  minimizing  “standby”  power  consumption,  to 
physically  partition  the  BIU  into  multiple  devices  using  either  “normal”  or  “standby”  power 
sources.  Isolated  power  inputs  may  be  provided  to  the  device  which  implements  the  Global-bus- 
rclated  control  functions  and  other  BIU  functions  to  minimize  superfluous  power  dissipation.  As 
a worst  case  estimate,  the  required  BIU  standby  power  was  assumed  equal  to  the  combined 
maximum  power  consumption  of  all  basic  Global  bus-interface-related  functional  hardware  (e.g., 
using  the  BIU  device  partitioning  uescribed  in  Section  VI,  the  associated  devices  are  1-BILU, 
2-B1TU,  1-RBMU,  and  two  line  driver/receiver  pairs).  Tlie  total  estimated  worst  case  power 
requirement  for  these  combined  hardware  functions  is  1.26  watts.  This  power  consumption 
converts  to  a battery  energy  supply  requirement  of  approximately  12  mA-hr. 

From  the  above  estimated  “standby”  power  requirements  of  the  PE  Memory  and  Global 
Bus  Interface  functional  units,  it  appears  that  a battery  with  a minimum  charge  capacity  of 
approximately  12.3  mA-hr  will  provide  sufficient  backup  capability.  This  charge  capacity  require- 
ment is  extremely  minimal  and  offers  a preliminary  indication  of  the  practicality  (physical  and 
economic)  of  the  approach.  (As  an  example  of  representative  battery  requirements,  present 
commercially  available  nickel-cadmium  AA  cells  are  typically  capable  of  400  to  500  mA-hr  at 
1.25  volts.)  Actual  battery  requirements  cannot  be  determined  without  detailed  power  supply 
design  and  various  military  environment  battery  characteristics  being  researched  and  analyzed. 

Tlius,  it  appears  that  the  “ultra-reliabk.*”  power  supply  approach  to  achieving  PE  memory 
fault  tolerance  to  power  failures  is  amcnabk-  to  low-cost  miniature-size  battery  solutions. 
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introducing  little  impact  of  overall  system  hardware  requirements.  The  only  realizable  impact  of 
the  above  standby  operation  approach  on  DP/M  pertains  to  ensuring  operational  integrity  of  the 
standby-powered  hardware  functions  while  other,  interrelated  hardware  functions  are  inoperative. 
It  is  proposed,  however,  that  standby  mode  management  can  be  easily  facilitated  with  proper  use 
of  the  CLEAR/RESET  signal  generated  from  within  the  “ultra-reliable’’  power  supply  unit  to  the 
PE  during  the  period  of  primary  power  failure.  This  signal  can  be  used  to  denote  standby  mode 
operation,  thus  allowing  the  memory  controller  and  bus  access  controller  logic  elements  to 
perform  operations  related  to  standby  mode  activities  only.  During  the  presence  of  this  signal,  all 
normal  operating  mode  signals/procedures  are  ignored  (e.g.,  the  Bus  Interface  Unit  performs  only 
the  duties  of  “passing*'  bus  control  when  its  access  slot  is  recognized).  Thus,  the  functional 
design  of  the  bus  access  control  related  hardware  elements  do  not  use  the  CLEAR/RESET  signal 
as  an  asynchronous  “reset.”  It  should  also  be  noted  that  from  an  implementation  viewpoint  this 
approach  requires  that  the  bus-access-control-related  sequential  logic  functions  be  implemented 
with  asynchronous  techniques  to  prevent  the  otherwise  attendant  requirement  for  PE  clock 
operation  also  during  standby.  Additionally,  all  interrlated,  inoperative  function  signal  interfaces 
ot  the  standby-powered  elements  should  be  designed  so  that  the  logical  value  of  such  signals 
received  are  “F  * ' SE"  when  unpowered.  These  hardware  design  impacts  are  not  considered  of 
great  significu  .e  to  hardware  complexity;  however,  they  will  require  a further  amount  of  design 
consideration/'  rification  to  ensure  correct  device  operation.  As  a depaiting  note,  the  whole 
consideration  of  PE  (specifically,  B1U)  “power  segregation”  may  be  strictly  academic  once  an 
actual  battery  choice  is  determined.  The  entire  PE  could  be  operated  in  a standby  mode  (forced 
“idle”  caused  by  the  CLEAR/RESET  signal)  with  an  estimated  battery  charge  capacity  of 
approximately  SO  mA-hr.  Thus,  battery-size  availability  may  result  in  the  use  of  a more  than 
adequate  capability,  allowing  simplified  PE  component  design;  or  the  incurred  penalties 
associated  with  battery  size,  cost,  and  reliability  due  to  the  greater  capacity  requirement  may  be 
negligible. 

The  techniques  of  battery  backup  power  supply  implementation  and  usage  are 
conventionally  well  known  aid  should  present  little  associated  design  risk.  The  functional 
attributes  of  the  power  supply  design  are  represented  in  Figure  183.  Furthermore,  with  proper 
physical  implementation,  ultra-reliable  PE  power  supplies  may  be  modularly  configured  from 
existing  equipment  (“standardized”)  power  supplies,  aircraft  device  power  supplies  may  be  easily 
upgraded  to  “ultra-reliable”  configurations  (for  “smart  sensors’ ).  or  the  backup  battery 
equipment  may  be  eliminated  from  deployed  power  supply  units  as  nonvolatile  semiconductor 
memories  become  available  and  are  used  in  DP/M  systems. 

Two  schemes  of  potential  physical  deployment  of  the  DP/M  PEs  and  associated  power 
supply  allocation  are  currently  envisioned.  One  scheme  is  to  physically  collocate  a PE  or  an 
Affinity  Group  with  a device  which  provides  primary  I/O  to  the  function  in  that  PE  or  Affinity 
Group.  In  this  “smart-sensor"  configuration,  the  PE/Affinity  Group  would  derive  its  power  from 
the  same  power  source  which  supplies  the  device  as  shown  in  Figure  184.  Therefore,  both  the 
device  and  Affinity  Group  would  be  affected  in  the  same  way  in  the  event  of  a power  failure. 
The  capability  would  exist  in  this  scheme  to  switch  tnc  device  on  and  off.  but  the  Affinity 
Group  may  require  continuous  power  (i.e.,  uiU«i-rciiable  power),  depending  upon  associated  PE 
memory  technology.  The  disadvantage  is  that,  should  an  Affinity  Group  member  PE  be 
connected  to  another  device  which  also  is  a primary  I/O  contributor  to  the  function  in  this 
Affinity  Group,  but  is  not  collocated,  separate  power  supplies  would  have  to  be  provideu  for 
each  PE. 
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Figure  183.  “Ultra-Reliable”  PE  Power  Supply  Functional  Block  Diagram 
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Figure  1X4.  Co- Located  PE(s(  and  Associated  Aircraft  Device  With  Common  Power  Supply 


In  the  other  configuration.  Affinity  Groups  are  suitably  located  in  various  parts  of  the 
aircraft  so  that  they  are  close  to  the  I/O  device  they  service  and  yet  can  be  connected  to  all  the 
power  buses  so  they  can  be  supplied  primary  aircraft  power,  even  in  the  most  degraded  backup 
mode.  The  disadvantage  of  this  scheme  is  that  some  devices  can  be  so  located  that  relatively  long 
I/O  cabling  may  be  required  from  Ft  to  device.  The  obvious  advantage  is  that  the  DP'M  system 
is  assured  access  to  the  most  reliable  elementary  power  system.  Also,  a power  supply  can  be 
provided  for  each  Affinity  Group  or  for  multiple  Affinity  Groups,  thus  improving  space  and  cost 
economy.  Power  suppiy  allocation  to  Phs  (i.e..  Alfinity  Groups)  is  dependent  upon  function 
cnticality  which  dictates  primary  secondary,  emergency  aircraft  power  bus  access.  Allocation 
option  ex  .mples  arc  shown  in  Eigurc  1X5. 

On  an  aircraft  with  multiple  power  buses,  thcic  is  one  consideration  in  connecting  a DP/M 
PE  and  its  external  "SSIU”  device  to  a given  sensor. actuator.  If  the  SSIlt  must  convert  synchros 
or  any  ac  transducers  that  require  a reference  voltage  for  conversion,  the  SSIL  and  sensor  must 
be  connected  to  the  same  power  bus  since  one  phase  of  the  ac  power  is  used  as  the  common 
conversion  reference  voltage.  This  particular  requirement  may  dictate  the  actual  power 
connection  configuration  between  a PE  and  the  sensor  to  which  it  is  interconnected.  Similar 
limitations  arc  likely  to  exist  when  a set  ot  sensors  is  to  be  configured  for  a given  suite  of 
avionics. 

In  summary,  the  important  observation  with  respect  to  DP'M  power  reliability  is  that  it 
meet  MIL-STD-704A.  regardk'ss  of  which  power  bus  it  is  connected  to.  Conversations  with 
tactical  pilots  and  examination  of  current  advanced  aircraft  system  studies  imply  that  the 
probability  ot  primary  power  failure  during  a mission  is  almost  negligible,  and  if  primary  power 


F ij  ure  185.  Physical  PE /Power  Supply  Allocation  Alternatives 


does  completely  fail,  the  safety  of  the  aircraft  becomes  of  prime  importance  and  the  mission 
would  most  likely  be  aborted.  An  additional  consideration  exists  if  the  aircraft  uses  a digital 
fly-by-wire  system:  processors,  voters,  and  actuators  must  be  supplied  with  a minimum  of 
30  minutes  of  backup  power  to  permit  return  to  base  and  the  controlled  landing  of  the  aircraft. 
This  requirement  for  sustained  operation  from  a fixed  backup  battery  source  (aircraft  primary 
battery  power)  encourages  the  use  of  low-power-consumption  processing  elements  such  as  the 
DP/M. 


F.  SUMMARY  AND  CONCLUSIONS 

This  paragraph  summarizes  the  fault-tolerance  analysis  and  assesses  the  impact  of  fault- 
tolerant  design  on  DP/M  system  characteristics.  The  DP/M  system  that  has  evolved  as  part  of  this 
study  incorporates  within  its  design  the  concepts  of  fault  tolerance  and,  as  such,  attempts  to 
implement  the  realization  of  a total  system  fault-tolerant  computing  capability.  The  DP/M 
system  as  designed  offers  a number  of  significant  advantages. 

The  system  can  detect  faults  and  initiate  remedial  action  before  damage*  r damaging 
information  propagates  through  the  system,  and  thus  offers  the  potential  of  truly  graceful 
degradation.  The  low-cost  homogeneous  building-block  concept  of  the  system  design  allows 
redundant  units  to  be  added  to  the  system  to  provide  fault  tolerance  for  critical  computational 
functions. 

A type  of  reconfiguration  presently  in  use  in  multiprocessor  systems  and  federated  systems 
involves  the  reassignment  and  reallocation  of  hardware  resources  to  functional  responsibilities  in 
response  to  various  system  component  failures.  This  reconfiguration  philosophy  can  impose 
special  hardware  requirements  (e.g.,  shared  resources,  such  as  memory)  and  requires  the 
development  of  complicated  reconfiguration  control  software.  Because  of  the  dedicated  nature  of 
some  of  the  DP/M  system  components,  and  the  low  projected  cost  of  future  LSI  microprocessors 
such  as  the  DP/M  PE,  reconfiguration  as  described  above  is  no  longer  practical  and  is  not 
supported  by  the  DP/M  system  design. 

As  described  in  previous  paragraphs,  each  aspect  of  system  design  has  paid  careful 
attention  to  the  consideration  of  fault  tolerance,  so  that  the  achievement  of  an  effective  level  of 
system  fault  tolerance  is  integral  to  the  system  building-block  components  and  will  not  require 
costly  future  “afterthought”  add-on  realization.  The  design  of  the  functional  hardware  elements, 
the  table-driven  executive  software  structure,  and  the  tightly-coupled  global  control  concept  with 
loosely-coupled  local  control  are  all  design  schemes  that  have  evolved  from  the  study  of 
alternative  tradeoffs  to  system-level  fault-tolerance  capabilities.  The  approach  taken  in  the  DP/M 
design  has  been  to  consider  the  oroblem  of  reliability  and  expandability  from  the  initial  stages  of 
the  system  design. 

Since  the  basic  distributed  functional  microprocessor-implemented  system  architecture  was 
determined  to  be  advantageous  to  improving  present  system  reliability  and  readily  amenable  to 
conventional  fault-tolerance  techniques,  no  real  impact  on  system-level  design  was  expected  or 
encountered.  The  only  impact  experienced  was  increased  hardware  complexity  in  the  PF.  design, 
caused  by  the  necessary  inclusion  of  certain  fault-detection  mechanisms  to  allow  system-level 
fault  tolerance  via  hardware  fault  detection  and  subsequent  software-controlled  recovery. 
However,  detailed  investigation  into  the  amount  of  added  complexity  required  for  the  detection 
mechanisms  showed  relatively  little  contribution  to  overall  unit  complexity  with  one  possible 


460 


exception  in  the  Bus  interface  Unit,  it  was  determined  that  elimination  of  the  seif-test  feature  of 
full-duplex  B1U  operation  with  the  individual  information  transfer  buses  could  result  m a 
potential  25-percent  reduction  in  the  most  complex  BIU  device  type.  It  is,  however,  realized  that 
this  tradeoff  cannot  be  decided  until  actual  device  technology  capability  versus  the  estimated 
requirements  are  determined,  a function  of  the  future  time  of  device  implementation. 

In  conclusion,  the  DP/M  system  offers  basic  architectural  and  component  design  features 
whicn  are  amenable  to  conventional  fault-tolerance  techniques.  Variations  in  this  technique  are 
facilitated  with  basic  fault-detection  capabilities  built  into  the  DP/M  component  designs;  with 
low  complexity  impact.  Unique  technique  hardware  requirements,  however,  must  be  added  as 
dictated  by  definitized  individual  system  fault-tolerance  requirements.  Thus,  upgradable,  “pay-as- 
you-go”  fault-tolerant  system  configurations  are  allowed  at  the  expense  of  only  those  applica- 
tions where  added  cost  is  justifiable;  the  potential  application  of  DP/M  systems  or  components  in 
fault-intolerant  applications  is  not  jeopardized  by  penalties  incurred  in  defaying  the  costs 
required  of  the  low-volume  sophisticated  fault-tolerant  applications.  Exrct  approaches  to 
fau';- tolerant  system  design  characteristics,  such  as  redundancy  technique  and  fault  recovery 
technique,  are  dependent  on  individual  system  requirements;  however,  it  appears  that  the  basic 
DP/M  concept  and  design  provides  the  necessary  functional  tools  with  which  a wide  variety  and 
varying  degrees  of  system-level  fault  tolerance  can  be  effectively  produced. 
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APPENDIX  A f 

BASIC  PROCESS  CONSTRUCTION  INPUT/OUTPUT  DATA  FILES  \ 

In  the  description  of  Process  Construction  input/output  data  files,  the  following  termi- 
nology is  used: 

(t)  The  term  “software  module”  denotes  any  software  component  under  consideration 
(and  also  the  corresponding  segment  of  the  execution-time  code),  which  may  be  a 
whole  program,  a task  (procedure)  of  that  program,  or  a subprogram  called  by  a 
task 

(2)  The  term  “data  set”  refers  to  the  nonexecutable  data  of  the  process  (such  as 
individual  variables,  arrays  consisting  of  such  variables,  records,  or  files)  which 
requires  storage  at  execution-time. 


FILE  NAME: 
DESCRIPTOR 
FORM. 
CONTENTS: 

I. 

n 

3. 


4. 


Computer-Independent  Model  of  the  Process  (Input  File) 

Exogenous  input  to  Step  1 of  the  Process  Construction  Procedure 
Card  images  constituting  a disk  file 

Process  model  ID/descriptor 

Number  of  programs  in  the  process  model 

For  each  program  in  the  process  model: 

3.1  Program  ID/name  and  type  code  (External  I/O  Handler,  avionics,  etc.) 

3.2  Name  of  the  avionics  (sub)  function  which  the  program  represents 

3.3  Scheduling  parameters: 

3.3.1  Iteration  rate 

3.3.2  Priority  classification 

3.3.3  Other  parameters  not  yet  identified 

3.4  Number  of  tasks  (procedures) 

3.5  ID  of  the  entry  task  (procedure) 

3.6  Number  of  interprogram  or  external  inputs 

3.7  Number  of  interrrogram  or  external  outputs 

3.8  For  each  int . .-program  or  external  input  used  by  the  program: 

3.8.1  Input  ID  and  type  code  (interprogram  or  external) 

3.8.2  Number  of  the  consumer  tasks  in  the  program 

3.8.3  IDs  of  all  consumer  tasks 

3.9  For  each  interprogram  or  external  output  produced  by  the  program: 

3.9.1  Output  ID  and  type  code  (interprogram  or  external) 

3.9.2  ID  of  the  producer  task 

3.10  Number  of  intraprogram-intertask  input/output  variables  used  within  the 
program 

3 1 1 For  each  intraprogram-intertask  input, 'output  variable: 

3.1  l.l  ID 'name  of  the  input  output  variable 

3.1 1.2  Type  code 

3.1 1.3  ID  of  the  producer  task 

3.1 1.4  Size  (=  number  of  bits) 

3.11.5  Production  rate 

For  each  task  (procedure)  in  every  program: 

4.1  Task  (procedure)  IDname 

4.2  Task  enumeration  number  within  the  program 

4.3  Permanent  memory  (=  number  of  16-bit  words) 

4.4  Temporary  memory  (=  number  of  1 6-bit  words) 

4 5 Minimum  and  maximum  numbers  of  repetitions  (loops)  per  one  execution 

of  the  program 

4.6  Processing  load  per  repetition 

4.6.1  Single  precision  operations 


Number  of  additions  subtractions 
Number  of  multiplications 
Number  of  divisions 


4.6.2  Double  precision  operations. 

Number  of  additions  subtractions 
Number  of  multiplications 
Number  of  divisions 
Number  of  logical  Boolean  operations 
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4.7 


4.8  Average  number  of  control  operations: 

Per  one  arithmetic  operation 
Per  one  logical  operation 

4.9  Calls  of  single  precision  standard  subroutines: 

Square  root 

Sine  ^Cosine 

Arctan 
Exponential 
Logarithm 
A'c  sin/ Arc  cos 

4.10  Calls  of  double  precision  standard  subroutines: 

Square  root 
Sine/Cosi  te 
Arctan 
Exponential 
Logarithm 
Arc  sin/ Arc  cos 

4.1 1 Number  of  nonstandard  tasks  (procedures)  called 

4.12  For  each  nonstandard  task  (ptocedure)  called: 

Task  iD 
Number  of  calls 

4.13  Number  of  successor  tasks  (procedures) 

4.14  For  each  successor  task  (procedure): 

ID  of  the  successor  task  (procedure) 

Probability  or  logical  condition  of  transition 

4.15  Number  of  intraprogram-intertask  inputs  used 

4.16  IDs  of  all  intraprogram-intertask  inputs 

4.17  Number  of  intraprogram-intertask  outputs  used 

4.18  IDs  of  all  intraprogratn-intertask  outputs 

5.  Number  of  interprogram  inpuis/outputs  in  the  process  model 

6.  For  each  interprogram  input/output: 

6.1  ID/name  of  the  input/output 

6.2  Type  code 

6.3  ID  of  the  producer  program 

6.4  Size  (=  number  of  bits) 

6.5  Production  rate 

7.  Number  of  external  inputs  in  the  process  model 

8.  For  each  external  input: 

8.1  iD/name  of  the  inpul 

8.2  Type  code 

8.3  ID/name  of  the  source  (i.e.,  of  the  External  I/O  Handler  program) 

8.4  Size  t=  number  of  bits) 

8.5  Production  rate 

8.6  ID  code  of  the  connecting  DP/M  ?E 

8."  ID  code  of  the  connecting  sensor 

9.  Number  of  external  outputs 

10.  For  each  external  output: 

10.1  ID/name  of  the  output 

10.2  Type  code 
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10.3  ID/name  of  the  producer  (i.e.,  of  the  External  I/O  Handler  program) 

10.4  Size  (=  number  of  bits) 

10.5  Production  rate 

10.6  ID  code  of  the  connecting  DP/M  PE 

10.7  ID  code  of  the  connecting  actuator 


FILE  NAME:  Report  on  Computer-Independent  Model  of  the  Process 

DESCRIPTOR:  Documentation  of  the  computer-independent  model  of  the  process 
FORM.  Computer-printed  report 

CONTENTS: 

This  report  is  a printed  version  of  and  has  the  same  contents  as  the  inputted  Computer- 
independent  Model  of  the  Process  (card  images  constituting  a disk  file).  In  addition,  this  report 
shall  contain  the  maximally-parallel  predecessor-successor  graph  and  a companion  program  graph 
for  each  program  in  the  process  model. 


FILE  NAME:  Computer  Hardware  Definition  (Input  File) 

DESCRIPTOR:  Exogenous  input  t<-  Step  2 of  the  Process  Construction  Procedure 

FORM  Card  images  constituting  a disk  file 

CONTENTS: 

1.  Computer  ID 

2.  Computer  Description 

3.  Memory  size  (-  number  of  16-bit  words) 

4.  Speed  of  single  precision  operations  (minimum  and  maximum  execution  times): 

4.1  Additicn/subtraction 

4.2  Multiplication 

4.3  Division 


5.  Speed  of  double  precision  operations  (minimum  and  maximum  execution  times): 

5 . 1 Addition/subtraction 

5.2  Multiplication 

5.3  Division 

6.  Logical/Boolean  operations  (average  time) 

7.  Control  operations  (average  time) 

8.  Subroutine  Linkage  (average  time) 

9.  Average  execution  times  for  standard  single  precision  subroutines 

9.1  Square  root 

9.2  Sine/Cosine 

9.3  Arctan 

9.4  Exponential 

9.5  Logarithm 

9.6  Arc  sin/Arc  cos 

1 0.  Average  execution  times  for  standard  double  precision  subroutines 

10.1  Square  root 

10.2  Sine/Cosine 

10.3  Arctan 

10.4  Exponential 

10.5  Logarithm 

10.6  Arc  sin/Arc  cos 

1 1 . Memory  Allocation  guidelines  for 

11.1  Single  precision  arithmetic  operations: 

Number  of  permanent  memory  words  per  operation 
Number  of  temporary  memory  words  per  operation 

1 1 .2  Double  precision  arithmetic  operations: 

Number  ot  permanent  memory  words  per  operation 
Number  of  temporary  memory  words  per  operation 

1 1.3  Subroutine  linkages,  logical  operations,  and  control  operations: 

Number  of  permanent  memory  words 
Number  of  temporary  memory  words 

1 2.  Bus  capacity 
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FILE  NAME:  Report  on  Computer  Hardware  Definition 

DESCRIPTOR:  Documentation  of  the  computer  hardware  model  for  which  the  process  is  to  be 
constructed 

FORM:  Computer-printed  report 

CONTENTS: 

This  report  is  a printed  version  >f  and  has  the  same  contents  as  the  Computer  Hardware 
Definition  input  file. 
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FILE  NAME:  I/O  Control  Data  File 

DESCRIPTOR:  Hardware-assignment  dependent  data  (produced  in  bw’n  7 of  the  Process 
Construction  Procedure)  for  controlling  (routing)  the  interprocessor  and 
external  I/O 

FORM:  Disk  file  compatible  with  simulator  inputs 

CONTENTS: 

The  contents  and  organization  of  this  file  are  dependent  on  the  design  of  the  traffic  control 
subsystem  within  the  DP/M  Executive(s).  Therefore,  this  file  cannot  be  specified  now.  However, 
its  contents  shall  be  similar  to  that  of  the  companion  Report  on  I/O  Message  Routing,  which  is 
specified  next  in  this  document. 


FILE  NAME:  Report  on  I/O  Message  Routing 

DESCRIPTOR:  A hardware-assignment-dependent  report  (produced  in  Step  7 of  the  Process 
Construction  Procedure)  defining  the  I/O  message  traffic  in  the  process;  its 
main  function  is  system  documentation 
FORM:  Computer-printed  report 

CONTENTS:; 


1.  Number  of  interprogram  I/O  messages 

2.  Number  of  external  I/O  messages 

3.  For  each  interprogram  I/O  message: 

3.1  ID/name 

3.2  Type  code 

3.3  Size  (=  number  of  bits) 

3.4  ID  of  the  producer  program  and  its  PE  assignment 

3.5  Number  of  consumer  programs 

3.6  For  each  consumer  program: 

3.6.1  Program  ID/name 

3.6.2  Program  PE  assignment 

3.7  Production  Rate 

4.  For  each  external  I/O  message: 

4.1  ID/name 

4.2  Type  code 

4.3  ID/name  of  the  consumer/producer  (i.e.,  of  the  External  I/O  Handler 
program) 

4.4  Size  (=  number  of  bits) 

4.5  Production  rate 

4.6  ID  code  of  the  connecting  DP/M  PE 

5.  Routing  list  for  all  interprogram  I/O  messages  (ordered  by  increasing  I/O  message 
IDs),  where  each  entry  contains: 

5.1  Message  ID/Name 

5.2  Type  code 

5.3  Size  (=  number  of  bits) 

5.4  Production  rate 

5.5  ID/name  of  the  producing  program 

5.6  PE  assignment  of  the  producing  program 

5.7  Number  of  destination  PEs 

5.8  IDs  of  all  destination  Pts 

6.  Entry/exit  points  of  all  external  I/O  messages  (ordered  by  increasing  I/O  message 
IDs),  where  each  entry  contains: 

6.1  Message  ID/Name 

6.2  Type  code 

6.3  Size  (=  number  of  bits) 

6.4  Production  rate 

6.5  ID/name  of  the  consuming/producing  External  I/O  Handler  (program) 

6.6  ID  code  of  the  connecting  DP/M  PE 

6.'/  ID  code  of  the  connecting  sensor/actuator 
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FILE  NAME:  Program  Execution  Control  Data  File 

DESCRIPTOR:  Hardware-assignment-dependent  data  (produced  in  Step  8 of  the  Process 

Construction  Procedure)  to  be  used  by  the  DP/M  Executive  to  control  program 
execution 

FORM:  Disk  tile  compatible  with  simulator  inputs 

CONTENTS: 

The  contents  and  organization  of  this  file  are  dependent  on  the  design  of  the  DP/M  Executive(s); 
hence,  this  file  cannot  be  specified  here.  For  a description  of  the  program  execution  control  data 
used  by  the  current  version  of  the  DP'M  Executive,  refer  to  the  section  describing  the  design  of 
the  DP/M  Executive. 
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FILE  NAME: 
DESCRIPTOR: 


FORM 
CONTENTS: 

The  content  of  this  report  is  dependent  on  the  design  of  the  DP/M  Executive  subsystem,  hence, 
it  is  not  specified  here.  For  a description  of  the  program  execution  control  data  used  by  the 
current  version  of  the  DP/M  Executive,  refer  to  the  section  describing  the  design  of  the  DP/M 
Executive. 


Report  on  Program  Execution  Control 

A hardware-assignment-dependent  report  (produced  in  Step  8 of  the  Process 
Construction  Procedure)  documenting  the  program  execution  control  data  to  be 
used  by  the  DP/M  executive 
Computer-printed  report 
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FILE  NAME: 
DESCRIPTOR: 

FORM: 

CONTENT 

I. 

3. 


4. 


5. 


Memory  Map  and  System  Configuration  File 
Endogenous  output  of  Step  9 of  the  Process  Construction 
Procedure  to  be  used  by  processor  simulators 
Disk  file  compatible  with  simulator  inputs 

Process  Model  ID/descriptor 

Number  of  Processing  Elements  in  the  DP/M  configuration 
For  each  Processing  Element: 

3.1  Number  of  external  software  modules  (i.e.,  those  not  nested  in  other 
software  modules)  such  as  tasks  (procedures),  standard  or  special 
subroutines  to  be  loaded  into  the  memory  of  the  PE  under  con- 
sideration 

3.2  Number  of  data  sets  (areas,  buffer  areas  files)  to  reside  in  the  memory  of 
the  PE  under  consideration 

3.3  For  each  external  software  module: 

3.3.1  Module  lD/name 

3.3.2  Loading  address 

3.3.3  Size  (=  number  of  16-bit  words) 

3.4  For  each  data  set: 

3.4.1  Data  set  ID/name 

3.4.2  Loading  address 

3.4.3  Size  (=  number  of  16-bit  words) 

Master  directory  of  all  software  modules  in  the  process  module,  each  entry 
containing: 

4.1  Module  lD/name 

4.2  Type  code  (designating  whether  a standard  subroutine,  special  subprogram, 
task  of  a progiam.  etc.) 

4.3  Size  (=  number  of  16-bit  words) 

4.4  PE  assignment 

4.5  Configuration  control/functional  descriptor 

Master  directory  of  ail  data  sets  in  the  process  model,  each  entry  containing: 

5.1  Data  set  ID/name 

5.2  Type  code 

5.3  Size  (=  number  of  16-bit  words) 

5.4  PE  assignment 

5.5  Configuration  control/functional  descriptor 
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FILE  NAME: 
DESCRIPTOR: 


FORM: 

CONTENTS: 


Report  on  Memory  Maps  and  System  Configuration 
Endogenous  output  of  Step  9 of  the  Process  Construction 
Procedure  to  be  used  by  the  process  designer  and  for  process 
documentation  purposes 
A computer-printed  report 

Same  as  the  Memory  Map  and  System  Configuration  File 


FILE  NAME:  Report  on  the  Correctness  of  F ogram  Structure 

DESCRIPTOR:  Output  of  Step  4 of  the  Proces-  Construction  Procedure, 
which  is  to  be  used  mainly  by  the  process  designer  as  a 
diagnostic  document 

FORM  Computer-printed  report 

CONTENTS: 

1.  Process  ID/name 

2.  Number  of  programs  in  the  process  mode! 

3.  For  each  program  i * the  process. 

3.1  A summary  description  <<:  the  input  program  model  containing: 

3.3.1  Program  i!<  time  and  type  code 

3.3.2  Number  of  tasks  (procedures) 

3.3.3  ID  of  the  entry  task  (procedure) 

3.3.4  For  each  task  procedure  in  the  program. 

(a)  Task  (represented  by  a node  in  the  program  graph) 
ID/name 

(b)  Task  ID  number  assigned  by  the  topological  ordering  sort 
(to  be  called  topological  ID  number) 

(e)  Number  of  links  pointing  to  the  task  (node),  which  is  equal 
to  the  number  predecessor  tasks 

(d)  Number  of  links  emanating  from  the  task  (node),  which  is 
equal  to  the  number  of  successor  tasks 

(e)  ID  name  of  each  successor  task  (node)  and  the  correspond- 
ing transition  probability  or  the  logical  branching  condition 

3.3.5  Transition  Probability  (or  logical  branching  condition)  Matrix 

3.3.6  Node  Adjacency  Matrix 

3.3.7  Path  Matrix 

3.3.8  List  of  all  execution  paths  through  the  program  graph,  each  path 

being  defined  by  an  ordered  list  of  task  IDs 

3.3.9  A summary  statement  on  the  correctness  of  program  structure, 
including  the  information  on  whether  the  designated  entry  and  exit 
tasks  (nodes)  actually  are  such  and  whether  there  are  no  loops 
through  the  tasks. 


FILE  NAME 
DESCRIPTOR 


FORM: 

CONTENTS: 

1. 

■> 

3. 


Report  on  Program  Synthetic  Models 

Output  of  Step  4 ot  the  Process  Construction  Procedure, 

which  is  to  be  used  mainly  by  the  process  designer  to  decide 

whether  the  current  decomposition  of  the  process  into  programs 

is  acceptable 

Computer-printed  report 

Process  ID/ name 

Number  of  programs  in  the  process  model 
For  each  program  in  the  process  model: 

3.1  Program  ID/name 

3 2 Scheduling  parameters  and  iteration  rate 

3.3  Number  of  tas'.»  (nodes) 

3.4  ID  of  the  **nt  y task  (node) 

3.5  For  each  ta*x  (node) 

3.5.1  Ta'Jc  ID/Name 

3.5.2  Permanent  memory  (=  number  of  16-bit  words) 

3.5.3  Temporary  memory  (=  number  of  16-bit  words) 

3.5.4  Estimate  of  the  minimum  run  time 

3.5.5  Estimate  of  the  maximum  run  time 

3.5.6  Minimum  and  maximum  number  of  repetitions 

3.5.7  lndegree  (=  number  of  predecessor  tasks) 

3.5.8  Outdegree  (=  number  of  successor  tasks) 

3.5.9  For  each  successor  task,  the  task  ID  and  the  transition  probability 
(or  the  logical  branching  condition)  to  that  task 

3.5.10  Number  of  intraprogram-intertask  inputs  used 

3.5.1 1 IDs  of  all  intraprograin-intertask  inputs 

3.6  Number  of  alternative  execution  paths  through  the  program  graph 

3.7  For  each  execution  path,  an  ordered  task  (node)  list  and  the  probability 
(or  the  logical  condition'  of  the  path 

3.8  The  worst  case  processor  loading  per  one  unit  of  real-time  by  the  program 

3.9  Memory  loading  by  the  program,  divided  into 

(a)  Permanent  memory  requirements  for  tasks,  data  sets,  and  the 
called  subroutines 

(b)  Temporary  memory 

3.10  Number  of  standard  and  special  subroutines  called  by  the  program 

3.1 1 List  of  the  called  standard  or  special  subroutines 

3.12  The  maximally  parallel  predecessor-successor  graph 

3.13  Number  of  interprogram  or  external  inputs 

3.14  Number  of  interprogram  or  external  outputs 

3.15  For  each  interprogram  or  external  input: 

3.15.1  Input  ID/name  and  type  code 

3.15.2  Size  (=  number  of  bits) 

3.15.3  Number  of  consumer  tasks  in  the  program 

3.15.4  IDs  of  the  consumer  tasks 

3.15.5  Arrival  rate 
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3.16  For  eac‘.r  interprogram  or  external  output: 


3.16.1  Output  ID/name  and  type  code 

3.16.2  Size  (=  number  of  bits) 

3.16.3  ID  of  the  producer  task 

3.16.4  Production  rate 

Number  of  intraprogram-intertask  input/output  variables  used  within  the 
program 

For  each  intraprogram-intertask  input/output  variable: 

3.18.1  ID 'name  and  type  code 

3.18.2  Size  (=  number  of  16-bit  words) 

3.18.3  ID  of  the  producer  task 

3.18.4  Production  rate 
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FILE  NAME:  Report  on  Hardware  Configuration  and  Assignments 

DESCRIPTOR:  Exogenous  output  of  the  Hardware  Resource  Allocation  Algorithm:  (Step  6 of 
Process  Construction  Procedure)  also  to  be  used  as  a diagnostic  report  by  the 
process  designer 
Computer-printed  report 

The  required  number  of  Procesring  Elements 

Projected  total  loading  of  the  bus  system  (the  term  “total”  here  implies  that  no 
sepaiation  of  the  bus  load  into  the  Local  and  Global  bus  traffic  components  is 
made). 

For  each  required  Processing  Element: 

3.1 

3.2 

3.3 


FORM: 

CONTENTS: 

1. 

2. 


Number  of  software  modules  assigned 
Number  of  data  sets  assigned 

List  ot  all  assigned  software  modules,  each  entry  containing: 


3.3.1  ID/name  of  the  software  module 

3.3.2  Type  code 

3.3.3  Permanent  memory  required 

3.3.4  Temporary  memory  required 

3.3.5  The  contribution  of  the  module  to  the  loading  of  the  processor 
time  per  one  unit  of  real-time 

3.3.6  The  contribution  of  the  module  to  the  bus  traffic 

3.4  List  of  ail  data  sets  that  require  memory  allocation 

3.4. 1 ID/name  of  that  data  set 

3.4.2  Type  code 

3.4.3  Size  (=  number  cf  16-bit  words) 

3.5  Projected  total  loading  of  the  processor  time  per  one  unit  of  real-time 

3.6  Total  loading  of  the  permanent  memory  (=  number  of  16-bit  words) 

3.7  Tetri  loading  of  the  temporary  memory  (=  number  of  16-bit  words) 

4.  List  of  all  software  modules  in  the  process  model,  each  entry  containing: 

4.1  ID/n.ime  of  the  module 

4.2  Type  code 

4.3  PE  assignment 

5.  List  of  all  data  sets  in  the  process  model,  each  entry  containing: 

5.1  ID/name  of  the  data  set 

5.  . Type  code 

5.3  PE  assignment 
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APPENDIX  B 


PROCESS  CONSTRUCTION  CASE  STUDY 
SIMULATION  REPORT 


PROCESSING  EtfcNCNT  C QNNEC  1 1 V I TV  SPECIHCMItN 


GLCBAL  PIS  CONNECTIVITY  t 2 3 A 5 6 7 6 

11  1?  1:  1*  15 


aff  imty 

GROUP 

number 

l CONNECTIVITY 

1 

AFFINITY 

C<»CUP 

NUMBER 

2 connectivity 

2 

AFFINITY 

corup 

NUMeE« 

3 CONNECTIVITY 

i 

AFFINITY 

GPCUP 

MUMPER 

A CONNECT  1 V IT Y 

A 

AFFINITY 

GPCUP 

fiUMPFP 

5 CONNECTIVITY 

5 

AFFINITY 

GROUP 

NUMBER 

6 CONNECTIVITY 

t 

AFFINITY 

GPCUP 

NUMBER 

7 CONNECTIVITY 

7 

AFFINITY 

GPCUP 

NUMBER 

8 CONNECTIVITY 

d 

AFFINITY 

r.«cup 

NUMBER 

9 CCNNECT  l V I T Y 

9 

AFFINITY 

GHCUP 

NUMBER 

lu  CONNECTIVITY 

11 

AFFINITY 

r.pcup 

NUMBER 

11  CCNNECT 1 V 1 1 Y 

12 

AFFIM  TY 

GPCUP 

NUMBER 

12  CONNECTIVITY 

13 

AFFINITY 

Gt-  CUP 

HUMBER 

11  CONNECTIVITY 

1A 

AFFINITY 

GPrup 

NUMBER 

l A CCNPFCTIVlW 

15 

0*JL  Vff*/  &&td( 
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AVIONIC  TASKS  TO  PROCESSING  UEHfNT  ASSIC-NNEHt 


PROCESSING  ELENENT 

TASKS  ASSIGNED  1 

11 

PROCESSING  ELEMENT 
TASKS  ASSIGNEO  Al 
PROCESSING  ELENENT 
TASKS  ASSIGNED  AS 

PROCESSING  ELENENT 
TASKS  ASSIGNEO  AS 
PROCESSING  ELENENT 
TASKS  ASSICNFO  A I 
PROCESSING  ELENENT 
TASKS  ASSIGNEO  51 

PROCESSING  EIE*H*T 
TASKS  ASSIGNEO  52 

PROCESSING  ELENENT 
TASKS  ASSICKED  53 

PROCESSING  ELENENT 
TASKS  ASSICNEO  57 

PROCESSING  ELENEJlT 
TASKS  ASSIGNEO  58 

PROCESSING  ELENENT 
TASKS  ASSIGNEO  59 

PROCESSING  ELENENT 
TASKS  ASSIGNEO  63 

PROCESSING  ELENENT 
TASKS  ASSIGNEO  65 

PROCESSING  ELENENT 
TASKS  ASSIGNEO  67 

PROCESSING  ELENENT 
TASKS  ASSIGNED  69 


1 

; 3 A S 6 

12  13  1A  IS  16 

2 

A9  50  i? 

3 

AA 

A 

A6 

5 

6 
7 

56  61 

a 

5A 

9 

157 

10 

11 

12 

13 

1A 

15 


7 

1? 


8 9 10 

1C  19  20 
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17:00:39 


t 

! ( 

i.  i 


1 


OPN  SIMULATION  test  CASE 

f QPPUTFB  UTItl/AllfK  Sl^F/FY  FEP  FPCEFSSCP  1 


12/19/74 
PAGE  1 


HE  POP  T STA*T  TP«-  S O.o 


FEFEP1  STCF  TIPE  * 0.100000 


NUPBE®  r F |^T*kBCPtS  SfovICC** 
TOTAL  INTFFruFT  SF^VIfl  Tl^f 
TOTAL  SYSTrPS  PROOF**  TIPF 
TOTAL  A*I»1  TTATICNS  PREGRAP  T|‘ 
TOTAl  loir  T IMF 


T I pf  LT1LI/ATICA  DATA 

* C 

* C.C 

* c.t?un 

F - C.C 

* 3.C7H1S7 


PFFCENT  * 9.0 

•EREENT  * PI. 9C 
PEPCENT  * 0.0 

•EPCtNT  « 79.70 


AVAILABLE  4F-OMV 
NAXIMU*  USFf 


*»E*'r«V  Ultl/ATlfA  DATA 

4996  . 

1H4C  AVERAGE  USED  « 1490 


NUNREP  nF  IKE.'-PINC  MESSAGES 
NUMBER  IF  OUTr.flV,  NESSACES 


MESSAGE  LTIL  I7ATICR  DATA 

* 44  INCOMING 

* 4i  Cl’TGf  1NG 


Pf SSACE*  PfSSEO  * 0 

PFSSACFS  NISSEO  « 9 

» ••«**«/.«  ..•*»«*»«**  «***•«* 


* 


t 


f 


OPP  SIPOI  ATI'JN  T-TST  CASE 

. rcppuTFv  utilizatick 

SUPPAPY  FC« 

PROCESSES  2 

1 7: CG:39  12/19/74 

PAGE  1 

REPORT  start  TIPF  * C.O 

PFPCRT  STrP 

TIME  * 

0.100000 

. TIP*  LTIllZATICA  oata 

• 

NU-BER  EF  HTFRRLP1S  SF»V1CEC 

* 

f 

• 

TOTAL  INTFRH.PT  SFRVICF  TIPF 

S 

3.3 

PERCFNT 

* 3.0 

TOTAl  SYSTEPS  PRCGRAP  T1PE 

X 

0.004112 

PERCENT 

* 4.17 

TOTAL  APPLICATICNS  PROGRA"  T1PE 

= 

0.  Cl  1440 

PERCFNT 

- 11.44 

TOTAl  10LF  MME 

- 

C.C  14361' 

PERCFNT 

* 84.9* 

. *F*»r«T  LT1I  IZITIOP  CATA  . 

AVAILABLE  PFPUAY  * 4096 

RAX  I PUP  USFC  * 3999  AVERAGE  USFO  « 3*99 


. MFSSAGF  LTIL IZATIEN  CATA  . 
NUPBFH  OF  INEEP1KG  PfSSACES  « 21  INCOMING  “FSSAGES  NISSEO  « 0 
NUNBER  PF  CUTGP1NG  NESSAGFS  « 14  CUTGCING  MESSAGES  NISSEO  « 0 
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»«•**»*♦*** 
12/10/74 
1*  ACC  1 


^PM  StMUIATIW  TFST  CASE  l It  C0t39 

. COMPUTER  UT  tL  12 AT ICN  SLMPAFV  FCR  PRCCESSCR  1 


report  start  ri**r  * 


REPCPT  STOP  TIME 


O.IOOOOO 


TIME  U1UZMICN  CATA 


HUMBER  CF  INTERRUPTS  SERVICED 
TOTAL  INTERRUPT  SERVICE  TIME 
TOTAL  SYSTEMS  PROGRAM  TIME 
TOTAL  APPl  KATIPCS  PRrGMM  TIME 
TOTAL  IDLE  TIME 


3.C 

c.ccceic 

C.G276EC 

C.C7E44? 


PERCENT  * 0.0 

PERCENT  * O.M 
PERCENT  - 22. 4« 

PERCENT  » 70.44 


MEMCfO  UTILIZATION  DATA 


AVAILABLE  memory  « 
MAXIMUM  USED 


AVERAGE  USED 


MESSAGC  UTIL IZATICN  DATA 


number  OF  INCOMING  messages 
number  OF  CUT GOING  MESSAGES 


INCOMING  MESSAGES  MISSFO 
CUTGCINC  MESSAGES  MISSED 


OPP  SI«UIAT  iru  TFST  CASE  17: C0:39  12/19/7A 

. CCMPITFR  IJTIU2ATIO  SOPAFY  Fffl  PRCCESSCR  5 MGF  I 


REPORT  START  TI*E  « 


C.O 


PCPCR1  STCP  TIPF  ■ 


0.100000 


. T(**r 

NUPHF*  CF  IMfRPIPTS  SERVICE 
rniAi  int*"  ari.pt  sfpvice  ti*p  « 

TOTAl  SYSTFPi  PPOGRAN  TIPS 
TOTAL  APPLI'ATICNS  f«OG»AP  TIME  * 
OTAl  1 CL  I TIPF 


lttli/atick  CATA 
C 

C.C 

C. CC24F3 

D. 33IM2 
C.C«SA7? 


PERCENT  « 0.0 

PERCENT  » 2.AI 
PERCENT  « 1?.»A 

PERCENT  - 59.A7 


. PF*CBY  IT  112AT1CN  CAT  A 

AVAIHIUS  RE^CRV  » AC96 

RAX  I "TIN  U<C«*  * 3C19  AVHUCC  USED 


3019 


. «<SAGF  tmi/ATICN  CATA 

NUPHFR  r>  iFfCPINC.  NfcSSACFS  * 7 INCO»ING  MISSACFS  NISSEO  « 0 

NUN^EP  OF  TUTGCINS  Mf  SSAGFS  * f CUTGt ING  MESSAGES  PISSFO  * 0 


OP*  SIHILATirN  TCST  CASE 


17-.C0S39 


CCNPUTFF  UT  II 1 7 AT ICK  SUPPAFV  FCP  FRCCESSCR  6 


12/T9/7A 
PAGE  1 


REPORT  START  TIPE  - 0.0 


«EPm  STOP  TIPE  • O.LOOOOO 


. TIPS  l T 1 1 ! 2 A 1 ! CN  CATA 

NUPPER  GF  INTERRUPTS  SERVICES'  « C 

TOTAL  INTERRUPT  SERVICF  T|PF  * UC 

TOTAl  SYSTEMS  PROGRAM  TIPF  = C.CCISEE 

TOTAl  APPlKAfirNS  RRCGPAP  TINS  * 3.*UC9«e 

TOTAL  ICIC  TIME  * C.C87 A*t 


PFPCENT  « 0.0 

PERCENT  « 1.99 

PERCENT  * 10. 9A 

PERCENT  « 07.9* 


. Pf VCRY  IT  It  I 2 AT |CN  CATA 

AVARARIF  MF V0R Y * AC96 

PAXIPUP  USFC  * ? 1 30  AVERAGE  USED 


2130 


. Nf < SAGE  ITI 117 ATICN  CATA 

NliPSER  OF  IFCCPINC  “ESSACFS  « fc  INCHING  n£SSACFS  N|SSF0  * 0 

NUPPER  Oc  CUTGOING  MESSRS  * 3 CUTGCING  PFSSACES  NISSEO  * 0 
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OM  SIWIUTHS  TEST  CASE  17»C3:39  12/19/74 

. CCMPUTCQ  UTIL  I 2*T ICA  ‘LKMFV  fCR  PRCCESSCR  T PACF  I 


REPORT 

START  TIME  « 0.0 

RCPCRT 

STCP  T |N£  « 

0. 

100009 

• 

T |MC 

UTllt/ATirX 

CATA 

• 

NUM3E0 

Of  IKTFPhLPTS  SERVICE'' 

B 

p* 

• 

TOTAL 

INTckcumt  SERVICE  T I MF 

B 

c.c 

PfRCFNT 

m 

0.0 

TOTAL 

SYSTEMS  PPOGRAM  TIME 

r 

C.GL3S84 

PEPCFNT 

9 

3.90 

TOTAL 

APPL IT  AT ICNS  PPOGRAM  T 1 MR 

Tt 

C.C12458 

PERCENT 

n 

12.4* 

TOTAL 

IDlf  T|Mr 

* 

0.CF358C 

PERCENT 

9 

• 3.55 

• 

MfRCRY  LTIl I2MI0N  PaTA 

• 

AV At  LA  °L E PtMCRY  » 

4096 

• 

MAXIMUM  USED 

2I9C 

average  usfc  * 

2190 

. MESSAGE  Utlll/ATIC*  Tiki* 

NtlMREP  OF  INCOMING  MfSSACfS  « 14  t*CC»tXG  MESSAGES  M1SSFO 

NUMAEP  OF  OUTGOING  MFSSACFS  « 12  CUTGCINC  -FSSAGES  KISSED 


DPM  SIMULATION  T«-ST  CASF  1 7: 00:39  12/19/74 

. COMPUTER  UTtLlZATtr*  SUMMAR*  FCF  PRCCE«SCR  H PAGE  I 


HEP0R1  START  TIKE  « 


PFFCPT  STCP  TIRE  « 


0.100000 


. T|o;  L'TfLI2AT|fA  CATA 

NUKREfi  OF  IMCSRLPTS  SFRVICCO  * C 

TOT»L  INTERRUPT  SFPVICE  Tt"F  * O.u 
▼OTAL  SYSTEMS  PflflGRAM  TIPF  * C.30235S 

TOT*  l APPI  1C  AT  I ONS  PROGRAM  T»*"E  * O.CIMSC 

TOTAL  ICLE  TIME  « O.CF27S5 


PERCE.  T » 
PERCENT  - 
PERCENT  - 
PERCENT  * 


0.0 

2.09 

15.19 

•2.75 
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OPP  SIMULATION  TT ST  CASF  17tCC:39 

. COMPUTER  OTIMZATICK  SUMMARY  FOR  PPOfFSSCR  9 


RFPORT  START  TJpe  . 


REPORT  STOP  TIME  * 


12mm 

PAGE  I 
0. 1 00000 


. TIPr  ttlt 12ATIEK  CATA 

NtJPMP  Cf  INTERRUPTS  U-VICCC  « C 

TOTAL  INTERRUPT  SRRVK*  T1"E  * 3.' 

total  systems  program  tipf  * c.ccsm 

TOTAL  APPLICATIONS  PROGRAM  TIME  * 0.CCS9S6 

TOTAL  IClF  TJMF  « 0.C8EE71 


PERCENT  • 0.0 

PERCENT  > I. ST 

PERCENT  ■ 9.96 

PERCENT  « 86.67 


«fc*f'RY  UTILIZATION  DATA 


AVAI LARI  F *F»0RY 
MAXI  RUM  USED 


AVERAGf  USED  « 


MESSAGE  UTILIZATION  CATA 


NUMBER  OF  INCOMING  *ESSA.J  S * 
number  of  outgoing  nfssagf-  * 


IKCOPINC  MESSAGES  PISSEU  * 
OUTGOING  MESSAGES  MISSED  « 


OPP  S I PUL  A T I ON  TEST  CASC  ITJ00J39  12/19/TA 

. COPPUTEP  UTIL  I Z AT IfK  SUMMARY  TCR  PROCESSORS  PAGE  I 


REPORT  START  TIRE  * 


RFPCRT  STOP  TINE  « 


0. 100000 


. TIPr  LT I t l ZAT ICR  CATA 

NUPBER  CF  IMTFRPUPTS  SERVICED  « C 

TOTAL  INTERRUPT  SERVICE  TIME  « O.C 

TOTAL  SYSTEMS  PRCGRAP  TIPE  » C.CC072* 

TOTAL  APPLICATIONS  PROGRAM  TIME  * 0.00202? 

TOTAL  IDLE  TIME  « 0. .9*2*1 


PERCENT  ■ 
PFRCENT  • 
PERCENT  * 
PERCENT  « 


0.0 

0.72 

3.02 

96.2? 


MFMOrjy  UTILIZATION  data 


available  PFMORY  « 

MAXI  MUM  USEr  * 


AVERAGE  USED 


MESSAGE  UTILIZATION  CATA 


NUMBER  OF  INCOMING  NESSACES 
NUMBER  OF  OUTGOING  MFSSAGES 


INCOMING  MfSSACFS  mjsSEO 
CUTGCING  MESSAGES  PISSED 


OPM  SIMULATION  f PST  CASF  I?:C0t39  12/19/74 

. COMP'jTfR  UtlLIZATICN  SUMMARY  FCR  PPCCLSSORJ1  PAGE  1 

RFPORT  START  ripr  * O.O  PfPCRT  STOP  TIME  « O.IOOOOO 


. TIME  UTIl 1ZATICN  DATA 

NUMBER  or  INTERRLPTS  SFRVIO.EC  = C 


TOTAL  IMTFRCLPT  SFRVICT  TI*»F 
TOTAL  SYSTEMS  PROGRAM  TI*»£  * 

TOTAL  APPLICATIONS  PROfUM  TIME  * 
TOTAL  I OLE  TIME 

C.C 

c.ccim 

3.3364F4 
C.C6 173C 

PERCENT  « 
PE»CFNT  * 
PERCENT  « 
PERCENT  * 

0.0 

1.79 

36.48 

61.13 

• 

MEMORY 

LTILI2A1  t»‘N  rATA 

m 

AVAILABl  t-  MfMORY  = 

<•09  h 

• 

MAXIMUM  USEO 

3419 

AVERAGE  USED  « 

3419 

• 

MfSSACF 

UT II IZATIGN  OATA 

• 

NUMHFR  f!F  INCOMING 

MESSACES  * 

6 INCOMING 

Mf  SSAGES 

M ISSEO  « 

0 

NUMBER  OF  OUTGOING 

MFSSACF S * 

27  CUTGCING 

MFSSAGFS 

>»«.*.***4 

MISSEO  « 

0 

******* 

9PM  SIMULATION  TEST  CASE 


17JC0:?9 


COMPUTER  UTHI7ATICN  StMNAFY  TCP  FRCCESSCR12 


12/19/74 
PAGE  1 


REPORT  START  TI«»e  * 0.0 


REPORT  STOP  TIME  * 0.100900 


. TIME  LTILI7A1ICN  data 

MUMPER  CF  INTERRUPTS  SERVICEC  * C 

TOTAL  INTERRUPT  SERVICE  TIME  = C.C 

TOTAL  SYSTFMS  PPOCPAM  T IMF  = 0.C02244 

TOTAL  APPLICATIONS  PROGRAM  T I MF  * 3.043568 

TOTAL  IDLt  TIME  * C.CS67EF 


PERCENT  * 0.0 

PERCENT  * 2.24 

PERCENT  « 40.97 

PERCENT  » 56.79 


. MfcMCRY  LTIl  IZA  T IC.N  OAT  A 

AVAILABLE  MFMORY  * 4096 

MAXIMUM  USED  * 3515  AVERAGE  USED  » 


3515 


. MESSAGE  UTILIZATION  DATA 

NUMBER  OE  INCOMING  MESSAGES  * 10  INCOMING  MESSAGES  MISSFO  « 0 

NUMBER  OF  OUTGOING  MESSAGES  = fc  CUTGCING  MESSAGES  MISSFO  » 0 
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OPM  Sl«'Jl  fTIUM  TEST  CASE  17:30:39  12/19/79 

. rCMPUTFf  UULIZATttK  SLMPAE7  rCE  FRtCESSC«tl3  PAGf  » 


REPURT  START  TIME  * 


EEFCP1  STOP  TJRF  * 


0.I0C000 


. TIME  L'T  !L  I Z *T  ICK  CATA 

NUHHFR  rr  IMFCPIOTS  S^VICFR  * C 

TOTAL  JN’ToruPT  SCCVICF  T f * c.c 

TOTAL  SYSTEMS  PPPCPAM  TIMF  * 3.C3175C 

TOTAL  Ac  PL  l C AT  l CAS  PKOCPAM  TIME  = C.C9626C 

TOTAL  I0L*  T|mf  . 0.C51SSC 


PERCENT  * 0.0 

PCPCENT  = 1.75 

PEPCEM  « 96.26 

PFRCEN1  * 51.99 


Ml.F  Y LTf  L 17  ATICK  DATA 


AVAILABLE  *-F**CPV  * 
MAXIMUM  USEP  « 


average  usfo 


. ^FSSACF  cm  1ZATICN  DATA 

NUMBER  CF  IFCGMING  MfSSACFS  * P INCrMIKG  MESSAGES  “ISS^P  * 0 

NUMBER  Of  C'ITGCIMG  MESS Al.tS  * A CUTGCING  MESSAGES  M|SSFO  * 0 

**»****«*+*•  * «***  .«****•***••«****  «** 


J*  *■*.**»  »»  *.»*«»*•».-*»*■•»-»»<»'•.**•»*.■■•*»#*»•*■•♦**•*•«*♦•**»****»  ******  #***•»* 

DPM  SIMULAT  |<"N  TFST  C Ac. f 17:00:39  12/19/79 

. fOMPUTTP  UTILIZATION  SUMMASY  FCy  F«CF r S SCR  14  PAGE  1 


| REPORT  START  T IMp  * 

c.o 

OEFCRT  STOP  TIME  * 

0. 

iooooo  ! 

• 

TIME  LTIUZATICK  CATA 

: I 

NUMBER  CF  IMCRPLBTS 

SFOVICCO  * 

C 

• 

TOTAL  INTERRUPT  S^VICT  T IMF 

G.C 

PERCENT 

* 

0.0 

TOTAL  SYSTEMS  PROGRAM 

TIME  * 

3.032659 

PFRCENT 

m 

2.69 

TOTAL  APPLICATIONS  PROGRAM  T I MF  * 

O.C22122 

PERCENT 

X 

22.12 

TOTAL  IOLF  TIME 

X 

C.C7SIE9 

PERCENT 

X 

75.18 

• 

MEMORY 

LTIl IZATICN 

RATA 

1 

• s 

AVAUARLF  MEMORY  * 

9396 

. 1 

MAXIMUM  USFO  * 

3139 

AVERAGE  USFO  * 

3139  J 

• 

MESSAGE 

UTIL IZATICA 

CATA 

• 

NUMBER  OF  1KCCMINC  MESSAGES  * 
NUMREP  OB  OUTGOING  MESSAGES  3 


IACCMING  MESSAGES  MISSED  • 
ruTGflNG  Mf SS ACES  MISSED  » 


! 

I 


i 


i 


f 


'IP*'  SI  MUl  A T * CN  TEST  CASE 

L7:co:39 

12/19/7A 

• 

COMPUTES  UTILIZATION  SUMMARY  FCR  PRCCFS$C»15 

PAGE 

1 

RE PORI 

STA3T  T I MR  - C.O 

SFFCRT  STCP 

TIRE  * 

0. 

100000 

• 

T IMF 

UT It  I 2 AT  IEN 

data 

• 

NUMBER 

CF  INTERRUPTS  SERVICE!)  = 

C 

• 

TOTAL 

INTERRUPT  SERVICE  TIME 

o.c 

PERCENT 

x 

0.0 

TOTAL 

SYSTEMS  PROGRAM  TIME 

0.502SCA 

PERCENT 

x 

B.AO 

TOTAL 

APPLIC-TICNS  PROGRAM  TIMf  = 

O.C52AC7 

PFRCENT 

X 

S2.A1 

TOTAL 

1CLC  TIMf 

C.CAACBS 

PFRCFNT 

X 

AA.09 

• 

MEMORY 

UTILIZATION 

DATA 

• 

• "of t uitwfiioi*  unm  . 

AVAILABLE  ME  “CFY  * 096 

MAXIMUM  USfr.  s M07C  AVFRAGf  USEC  * *070 


. MESSAGE  UTILIZATION  DATA 

NUMBER  OF  INCOMING  MFSSAGES  * 2C  INCOMING  MESSAGES  MISSEO  « 0 

Nil  MM  EM  Oc  CllTGCING  M^SSACFS  * 12  CUTCCING  MFSSAGES  MISSED  « 0 


PUS  TRAFFIC  OhCrMPCSlTlCK  FC»  Lf CAL  BUS  9 


r 


TOTAL  TRAFFIC 
TRAFFIC  UTILIZED  FCR  DATA 
TRAFFIC  UTILIZED  FOR  rtEAOFR  » 
TRAFFIC  UTILIZED  FCR  SYNC 
TRAFFIC  UTILIZFD  FCR  GAP 


0.8*  KePS 
C.3A  REFS 
O.B*  KBPS 
3.08  KBPS 
O.IC  KBPS 


AC.*8  PERCENT 
AC.  *8  Pf °CENT 
7.IA  PFRCENT 
11.90  PERCENT 


****** 
* ***** 

*********** 

►•*•**< 

>**»#•< 

PUS 

>******* 

******** 

TRAFFIC 

«*•*»  ************* 

OFCCMPCSniCN  FCR 

I****** 

>•***•* 

LCCAL 

PUS 

10 

total 

****** 

TRAFFIC 

l*********i 

»****•! 

S 

******** 

0.0  KBFS 
****************** 

****** 

>**•**1 

BUS 

******** 

TRAFFIC 

CECCMPCSITICN  FCR 

>••***• 

LCCAL 

PUS 

11 

TOTAL 

TPAFF  IC 

X 

o.o  *eFs 

BUS 

TRAFFIC 

CFCrMFCS IT ICN  FCR 

ICC  Al 

****** 

EDS 

*****1********  ******* 
12 

TOTAL 

****** 

TRAFFIC 

►*•**•****< 

X 

u.o  *eps 

****** 
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PUS 

H-P+-  ♦ « % *t 

TRAFP  I T 

f t#******'»-*#**»*-M 

nprC^FCSITlTK  IT* 

LFCAl 

l $*+*  + 

PUS 

'»  ***  *¥*• 
n 

•A  * * ********** 

TOTAL 

**•**< 

TRAFFIC 

>*»*<  *********  **« 

s 

C.C  KPPS 

>*•**4 

>•*«*•*• 

FLS 

>♦*  > « 
t*  Arne 

CEFfKPCSmCK  FCP 

LCCAl 

»**♦*! 

PU5 

>••*««*» 

1 A 

TOTAL 

TRAFFIC 

2 

k **» **•*! 

C.O  KPFS 

**«**#*. 

>****i 

1 ******* 

************* 

FUS 

TP  A F F IF 

CfrcPPrsnitK  FCP 

GICPAL 

PLS 

RQ 

TOTAL  Ttarric 
TRAFFIC  UTU  I / EC  FOR 
TRAFFIC  UTUIZFP  FrP 
TRAFFIC  UTIlIZFr  rC« 
TRAFFIC  'JTUIZFO  FPA 


= PA.fT 

P AT  A = 

HtAOfP  = 2b.  67 

SYKC  = A. 52 

GAP  * 7.5* 


KPFS 

KPF5  55. A2  PFPCEM 
KPFS  TO. 32  PEHCFNT 
KPFS  5.35  PfPfFM 
HEPS  5.52  PfoCFVT 
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LIST  OF  ABBREVIATIONS 


ac 

Alternating  Current 

AG 

Affinity  Group 

AGE 

Aerospace  Ground  Equipment 

ALU 

Arithmetic  Logic  Unit 

AND 

Logical  And  Operation 

ANS 

American  National  Standard 

ARINC 

Aeronautical  Radio,  Inc. 

ATC 

Autonomous  Transfer  Channel 

ATCL 

Autonomous  Transfer  Control  Logic 

ATCR 

Autonomous  Transfer  Control  Register 

BC 

Branch  On  Condition  Long  Instruction 

BCD 

Binary  Coded  Decimal 

BCS 

Branch  On  Condition  Short  Instruction 

BDWT 

Bus  Dominance  Watchdog  Timer 

BGR 

Bus  Grant  Signal 

B1LR 

Branch  Indirect  And  Link  Register  Instruction 

BILU 

Bus  Interface  Logic  Unit 

BIT 

Built-in-Test 

BITU 

Bus  Interface  Translation  Unit 

BIU 

Bus  Interfax  Unit 

BMI 

Bus  Master  Internee 

BPC 

Basic  Process  Constructor 

BQWT 

Bus  Quiescence  Watchdog  Timer 

BREL 

Bus  Release  Signal 

BRQ 

Bus  Request  Signal 

BSI 

Bus  Slave  Interface 

BSSCAN 

Branch  Successor  Scanner 

C 

Constant  Instruction  Modification 

CAS 

Close  Air  Support 

CAW 

Command  Address  Word 

CCD 

Charge-Coupled  Device 

CDMG 

Computer-Dependent  Model  Generator 

Cl  MG 

Computer-Independent  Model  Generator 

C2L 

Current-Coupled  Logic 

CLR 

Gear/ Reset  Signal 

CMOS 

Complementary  Metal  Oxide  Semiconductor 

CPC 

Current  Position  Of  Control 

CPU 

Central  Processing  Unit 
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D 

Direct  Instruction  Modification 

DAIS 

Digital  Avionics  Information  System 

dc 

Direct  Current 

DIP 

Dual  In-Line  Package 

DISPIN 

Scheduler  Service  Module 

DMA 

Direct  Memory  Access 

DP/M 

Distributed  Processor/Memory 

DTL 

Diode  Transistor  Logic 

DX 

Direct  Indexed  Instruction  Modification 

ECDG 

Execution  Control  Data  Generator 

ECL 

Emitter-Coupled  Logic 

ECM 

Electronic  Countermeasures 

EFL 

Emitter-Follower  Logic 

EIA 

Electronics  Industries  Association 

FBW 

Fly-by-Wire 

FCLK 

Free-Running  Clock  Signal 

FEL 

Future  Event  List 

FIFO 

First-In/First-Out 

GBPR 

Global  Bus  Position  Register 

GEX 

Global  Executive 

GEXSCHED 

Global  Executive  Scheduler 

G/L 

Global/Local 

HRAA 

Hardware  Resource  Allocation  Algorithm 

HS-RAM 

High  Speed  (Read/Write)  Random  Access  Memory 

Hz 

Hertz  (Cycles) 

IAK 

Interrupt  Acknowledge  Signal 

IAR 

Input  Address  Register 

I-BUS 

Internal  PE  Bus 

IC 

Integrated  Circuit 

ID 

Identification,  Identifier 

IDR 

Input  Data  Register 

llL 

Integrated  Injection  Logic 

ILR 

Input  Length  Register 

ILS 

Instruction  Level  Simulation 

IMQ 

input  Message  Queue 

IMSCAN 

Input  Message  Scanner 

INHB 

Interrupt  Inhibit  Signal 
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INTI 

Interrupt  Interface 

IOCDG 

I/O  Control  Data  Generator 

IODI 

Input/Output  Data  Interface 

IOIU 

Input/Output  Interface  Unit 

IOLU 

Input/Output  Logic  Unit 

IOSA 

I/O  and  Storage  Analyzer 

IQP 

Input  Queue  Pointer 

IRQ 

Interrupt  Request  Signal 

K 

Kilo  (Thousand) 

Kbps 

Kilo  Bits  Per  Second 

KIPS 

Thousand  Instructions  Per  Second 

LED 

Light-Emitting  Diode 

LEX 

Local  Executive 

LRU 

Line  Replaceable  Unit 

LSI 

Large-Scale  Integration 

LS-RAM 

Low-Speed  (Read/Write)  Random  Access  Memory 

mA-hr 

MiiUampere  Hour 

Mbps 

Megabits  Per  Second 

MBVS 

Message  Buffer  Vector  Space 

MCLK 

Master  Cock  Signal 

MIAA 

Message  Identity  Associative  Address 

MIAMM 

Message  Input  Associative  Match  Map 

MNOS 

Metal  Nitride  Oxide  Semiconductor 

MOS 

Metal  Oxide  Semiconductor 

ms 

Millisecond 

MSB 

Most  Significant  Bit 

MSI 

Medium-Scale  Integration 

MSTP 

Master  Stop  Signal 

MTBF 

Mean  Time  Beiween  Failures 

mW 

Milliwatt 

NARBS 

Night  Angle  Rate  Bombing  System 

NMOS 

Negative  Channel  Metal  Oxide  Semiconductor 

NPRZ 

Number  of  Predecessors 

NRZ 

Non-Return  to  Zero 

ns 

Nanosecond 

OAR 

Output  Address  Register 

OLR 

Output  Length  Register 

f 
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OMRQST 

Output  Message  (Request)  interpreter  Module 

OR 

Logical  Or  Operation 

PAP 

Process  Analysis  Program 

PATS 

Performance  Assurance  Test  Software 

PC 

Program  Counter 

PDIS 

Process  Development  Information  System 

PE 

Processing  Element 

PIO 

Pseudo  Input/Output  Instruction 

PIT 

Programmable  Interval  Timer 

PLA 

Programmable  Logic  Array 

P/M 

Processor/ Memory 

PMOS 

Pcsitive  Channel  Metal  Oxide  Semiconductor 

R 

Register  Instruction  Modification 

RAM 

(Read/Write)  Random  Access  Memory 

RBM 

Redundant  Bus  Management 

RBMU 

Redundant  Bus  Management  Unit 

RF 

Register  File 

Ri 

Register  Indirect  instruction  Modification 

RIA 

Register  Indirect  Autoincrement  instruction  Modification 

ROM 

Read  Only  Memory 

RR 

Register-To-Register 

RT 

Real  Time 

SCA 

Simulation  Control  Algorithm 

SOS 

Silicon  On  Sapphire 

SOW 

Statement  of  Work 

SSI 

Smal-Scale  Integration 

SW 

Status  Word 

TACK 

Transfer  Acknowledge  Signal 

TCEP 

Task  Completion  Entry  Point 

TDM 

Time-Division-Multiplex 

TRQ 

Transfer  Request  Signal 

TTL 

Transistor -Transistor  Logic 

USAF 

United  States  Air  Force 

V 

Volt 

VMD 

Virtual  Message  Distributor 

